Masternode payment queue

[Yourict]

Hello,

What is the logic behind the randomness in the selection of one masternode from the top 10% to recieve the payment, instead of it being simply THE one masternode at the top of the list?

Thanks.

 

[GrandMasterDash]

It's something to do with security i.e. if you know which one is next, attacks might be easier.

 

[Yourict]

Could you please be more specific? i have read most of the dash documentation, yet i found no official explanation for this.

 

[splawik21]

Could you please be more specific? i have read most of the dash documentation, yet i found no official explanation for this.

Hope that helps
https://docs.dash.org/en/stable/masternodes/understanding.html#payment-logic

 

[Yourict]

Hope that helps
https://docs.dash.org/en/stable/masternodes/understanding.html#payment-logic

Thanks.

I understand perfectly the "How", but not the "Why", GrandMasterDash sait that it was about security, i can't picture the type of attack that this system is made to counter.

 

[strophy]

DDoS is the type of attack this is designed to counter. If a masternode needed to be responding to pings and providing services for e.g. the 10 blocks before it was due for payment, it would be trivial to attack every masternode in that position and force your masternode to the front of the list faster. Randomising the selection pool solves this problem. Not very elegant, but effective. In future versions, this system will be replaced by a Proof of Service score. While this DIP has yet to be published, you can read details of how it will be applied here: https://github.com/dashpay/dips/blob/master/dip-0003.md

 

[Yourict]

it would be trivial to attack every masternode in that position

Do you mean DDoSing the masternodes in the 1 to 9 positions to make them miss their payment due to bad activity score, and have ones masternode recieve the reward instead?

 

[strophy]

Correct, assuming that was the point at which the critical payment decision was made if the current deterministic selection system from a 10% pool was not in place.

 

[Yourict]

Perfect, thank you.

 

[vasazuzuhi]

It's something to do with security i.e. if you know which one is next, attacks might be easier.

You could change the code and compile your masternode, so that it will not delete the quorum data but save it in a database. Then you could exchange the data with other masternodes or sell it.

 

[GrandMasterDash]

You could change the code and compile your masternode, so that it will not delete the quorum data but save it in a database. Then you could exchange the data with other masternodes or sell it.

The buyer(s) would still have to attain a lot of masternodes - more than 10% - before they attempt part one of a quorum attack. After that, you still have PoW to defeat. But in all honesty, it would be interesting to see someone attempt it, to either prove it's robustness or allow us to improve upon it. To my knowledge, quorum attacks are a bit thin on the ground.

 

[vasazuzuhi]

To my knowledge, quorum attacks are a bit thin on the ground.

Quorum attacks for BTC maybe. But what about quorum attacks for Dash? Has anyone tried them?