Hi, some questions about instantx.
1. My understanding is that all nodes will reject blocks that contains a double spend based on the transaction locks. Is this correct?
2. If so, can't masternodes vote on two different transaction locks, sending one out to one half of the network, and sending another to a second half. Now presuming all nodes see both locks there is no problem because both locks will be rejected, but a node that is not particularly well connected might only see one and assume the transaction lock is valid when it has been rejected by the rest of the network. This will effectively force the ill connected node to reject a block that will be accepted by the rest of the network.
3. Do new nodes download past transaction locks when verifying blocks? How do you guarantee consensus when transaction locks are not protected by proof of work.
4. Does Instantx effectively make dash into a hybrid POW/POS system? Why or why not?
Sorry I'm late to the party :wink:
1. Yes
2. There's multiple layers of defense against this type of attack. First off, the masternode network reduces the network propagation latency to about 4 seconds from side to side. That means you would need to propagate the conflicting transaction within that amount of time, otherwise the second one would be rejected, even while the first transaction lock was being created. But let's say you managed to propagate from both edges of the network, now you need to get your 2 confilcting transactions to their respective masternode quorums, which are picked randomly (deterministically using an algorithm defined in the IX paper), without hitting any of the masternodes that are seeing the other transaction, that seems unlikely alone.
But let's say you managed to do that by directly connecting to each of the masternodes and really planning this attack out. So you propagate both at exactly the same moment and get two transaction locks that are locking the same inputs. You would see a transaction lock for a brief second, then they cancel out and proof-of-work takes over. Look at CheckForConflictingLocks in instantx.cpp for more information.
As for your example about a node that isn't well connected and got only one of the locks? They might get stuck until they can get the second lock (which TCP/IP is really good at). As soon as they get that second lock, they will reconsider the block and continue on.
3. Up to version 12.0 this is true, it might not be true in the next version
4. Masternode quorums get their security from proof-of-work. It's a new type of blockchain based security, that allows us to do things not usually possible in normal blockchain based setups.
But instantx is not proof of work. And since your block consensus now relies on something that is not proof of work, you have introduced new problems. Below is example:
Bob votes for a transaction lock 1 where unspent A is sent to address B.
Bob also votes for another transaction lock 2 where unspent A is send to address C.
Bob then creates a transaction X where unspent A is sent to address B.
Bob now can broadcast transaction lock 1 and 2 however he pleases. If a node receives both locks, transaction X is valid. If a node recieves lock 1, transaction X is also valid. But if a node only receives lock2, transaction X is invalid. How does a node know which state is the correct one? Even if a node receives both locks, he can't know for certain whether the rest of the network also recieved both locks, or whether they only received lock2. The only way to know is by querying the majority of the network and seeing which state it wants to go into. Note that this is the exact thing that proof of work was created to avoid. With proof of work, you only need to connect to one honest node for it to work. Instantx makes network topology and connectivity extremely important.
So maybe we need to dive further into Masternode Quorums. This is a new concept in crypto that is very poorly understood, but greatly important for all of the technology that Dash employs. There's 2900 masternodes presently, each costing $3700, that's a total of $10M dollars that's in the masternode system at this point. A masternode quorum uses a recent blockhash to calculate 10 masternodes responsible per quorum, so all clients know who is responsible for which task. So when you propagate a transaction lock to the network, you'll need at least 5 other masternodes to sign those transaction locks. Let's say you have 100 masternodes on the network and you want to try and trick the system, here's a rough estimate of your chances:
(100/2900.0)**6 == .000000000168117
So you can't simply vote on a transaction lock. You need to be elected, along with 5/9 other random people that would have to be complicit. You don't pick the masternodes either, the proof-of-work hash does, which is why it inherits the security. This allows the network to perform highly secure things, with just a few nodes, then the rest of the network can trust that it was done correctly and not tampered with. As the market cap goes up and we get a more and more decentralized masternode network, the security of instantX and related technologies will also go up exponentially. Imagine on average each masternode was owned by 3 people, utilizing masternode shares.
I'm going to start making videos detailed how all of this works in great detail. It's something I can't do justice in a few paragraphs. There seems to be a huge misconception about how the security model works, hopefully I can correct that.
the transaction is in block chains. So, it's POW protected.
