InstantSend Double Spend in Theory vS in Practice

[jk404]

I am reading the code of instantx.cpp and I am confused on how an adversary can double spend.

What confuses me is the fact in my understanding, a master node is voting yes/no on "if a particular input was previously spent" without knowing who else is participating in the quorum. By this, there exists the risk of voting maliciously, and the rest 9 honest votes to vote honestly, therefore you are suspected and banned under some situations. So my first question is if it is possible after the latest updates in the new version to somehow know who are the rest participating in the quorum.

Finally, is there any way for an attacker to "program" or instruct his master nodes as to whenever they see a specific input to vote in favour of it?

 

[thephez]

You may find this helpful - https://dash-docs.github.io/en/developer-guide#instantsend (particularly the video).

I am reading the code of instantx.cpp and I am confused on how an adversary can double spend.

As long as things are working, an adversary cannot double spend.

What confuses me is the fact in my understanding, a master node is voting yes/no on "if a particular input was previously spent" without knowing who else is participating in the quorum.

The composition of the quorum doesn't have any bearing on if the input was previously spent.

So my first question is if it is possible after the latest updates in the new version to somehow know who are the rest participating in the quorum.

The quorum selected for an InstantSend is selected in a deterministic way (so you can tell which masternodes are allowed to vote on a given input). Additionally, quorums are selected per input. So if your transaction has 3 inputs, there will be 3 quorums of 10 masternodes each. Meaning in that case there need to be at least 18 yes votes to successfully InstantSend. If any of those quorums doesn't have a majority "yes" vote, the entire transaction will fail to get an InstantSend lock.

Finally, is there any way for an attacker to "program" or instruct his master nodes as to whenever they see a specific input to vote in favour of it?

Someone could theoretically create a modified version of Dash Core to vote a particular way for an input. But to be successful, that would require them to:

1. Be selected as part of a quorum voting on a transaction using that input
2. Control at least 6 of the 10 masternodes in the quorum to actually determine the vote

That is assuming the transaction has a single input. Regardless, the odds are astronomical. I think someone has done the calculations, but I am not sure where they can be found.

 

[jk404]

The quorum selected for an InstantSend is selected in a deterministic way (so you can tell which masternodes are allowed to vote on a given input)

I still don't understand something and pleaser answer this specifically: in an ecosystem of 4600 master nodes, an attacker who controls 6 masternodes, how can he know for sure that his 6 masternodes are going to be included in those 10? How can he know the rest of 4594 in such detail so that he can simulate such a scenario for a specific input?

Does this mean that *anytime* in the future, assuming that those 10 master nodes are active, they will be always selected for that specific input? What if new master nodes are registered with hashes falling in between of those selected? Thanks for the response and the link on InstantSend above, however, can you please clarify if in the latest version on what is the quorum selection based on? (I am unsure if it is on the hashing of MN vin , MN collateral address or MN id returned in debug console, and this confusion stems from what is changed on the latest release to protect against the November 2017 edge case found).

Moreover, I was trying to register a master node in the testnet and I since I follow the steps provided in the documentation where a user is required to open the debug console and by providing 2 commands to get the collateral address to which he will send the collateral plus the MN identifier, I do not see how this is protecting against the vulnerability of brute forcing the MN quorum for a specific hash.

Someone could theoretically create a modified version of Dash Core to vote a particular way for an input.

Can you explain how an attacker can do this? I am trying to see how (easy) someone can fool me with a modified Dash Core version. Do you mean to fork the code and change it for particular inputs? This does to apply to MN, but to the whole currency then.

 

[thephez]

I still don't understand something and pleaser answer this specifically: in an ecosystem of 4600 master nodes, an attacker who controls 6 masternodes, how can he know for sure that his 6 masternodes are going to be included in those 10? How can he know the rest of 4594 in such detail so that he can simulate such a scenario for a specific input?

If you really want to understand this, your best bet is to read the code related to how masternode rank is calculated (I think this is the PR that did most of the IS fixes).

Does this mean that *anytime* in the future, assuming that those 10 master nodes are active, they will be always selected for that specific input? What if new master nodes are registered with hashes falling in between of those selected? Thanks for the response and the link on InstantSend above, however, can you please clarify if in the latest version on what is the quorum selection based on? (I am unsure if it is on the hashing of MN vin , MN collateral address or MN id returned in debug console, and this confusion stems from what is changed on the latest release to protect against the November 2017 edge case found).

No, that would only happen if the masternode list never changed. Every time the list changes, quorums are going to get shuffled. Also, I doubt I can give a clearer explanation than the one presented in the video. I think it is towards the end of the video where he describes how it works following the 12.2 release, but I would watch the whole thing.

...I do not see how this is protecting against the vulnerability of brute forcing the MN quorum for a specific hash.

The masternode score calculation now includes the hash of the block that is 15 blocks after the masternode is registered (see around 13:30 in the video). So you literally *can't* calculate the score for a masternode that hasn't been registered/confirmed.

@UdjinM6 @codablock may be able to give some better info or correct anything I got wrong.

 

[jk404]

I read the code, what I don't get is what information is disclosed to a masternode owner about other masternodes and how an attacker could recognise one of his other masternodes (say he controls 2) while participating in the quorum.

 

[codablock]

I read the code, what I don't get is what information is disclosed to a masternode owner about other masternodes and how an attacker could recognise one of his other masternodes (say he controls 2) while participating in the quorum.

A quorum participant always knows all the other participants. Actually, the whole network knows all participants of the quorum, as otherwise the individual nodes (including the receiver of the IX) would not be able to verify the votes/locks. So, the attacker could easily identify all his members in a quorum.

Can you explain how an attacker can do this? I am trying to see how (easy) someone can fool me with a modified Dash Core version. Do you mean to fork the code and change it for particular inputs? This does to apply to MN, but to the whole currency then.

I think what thepez means is that an attacker can run his own modified version of Dash Core with modifications to trick the system. But to make this work out, the attacker would have to be lucky and control 6 of the quorum masternodes which would run his modified software. This is very unlikely (like...near impossible) due to the way we calculate quorums.