So when you propagate a message to your peers on the Dash network, you basically say "Hey, I have this new item in my inventory". Say you send it to 8 peers, afterward they each send the inventory to the peers they're connected to and so on. After a few hops, the whole network will have been reached. When I say our network has propagation rates of 4 seconds from end to end (absolute worst case currently), it means we require very few hops to propagate a message and our architecture is also hosted on low latency servers for the most part due to the reward/incentive system.
Our really low propagation rates are because of the masternode network hyper-connectedness. Each masternode, has 20-100 connections to other nodes. So from one side of the network to the other is just a few hops.
It starts with a client submitting an "ix" request instead of the normal "tx" message. That happens in wallet.cpp:1082. As messages propagate the network, they hit ProcessMessageInstantX (instantx.cpp:35)
At this point masternodes check if they're in the quorum in DoConsensusVote, via GetMasternodeRank. nBlockHeight is calculated by the block hash the transation in question was first included in. As consensus votes propagate the network, they're compiled in ProcessConsensusVote (instantx.cpp:305). Once they reach 6 of 10 votes, a lock is formed.
If a block arrives after a lock is formed, it will be rejected in main.cpp:2939.
If a miner decides to mine a chain a few blocks long, that includes a conflicted transaction, then somehow gets the lock after his blocks are accepted, once the lock is formed the chain will be flagged as invalid and removed at instantx.cpp:117.
Yes if you managed to pull off an attack you end up with normal pow, which is OK. The system only degrades to POW under very unlikely attack situations that are detectable. In that case you weren't able to rip anyone off and the rest of the 99.999% of people using the system experienced no issues and continue to have access to instant transactions. The general idea is we can have most transactions enjoy the instantaneous nature, if the system is attacked it will be detected and a downgrade to pow will happen. It's a win-win.
As for the logic that will reject the second txlock request, it's instantx.cpp:74. The masternodes will not accept 2 conflicting transactions. The second will not make it past that line, therefore getting no signatures.
