Question about quorum security

  • Thread starter Thread starter toknormal
  • Start date Start date
T

toknormal

Guest
Hi

In the Evolution docs it says:

To stop Masternodes from colluding, we base the deterministic selection algorithm on the proofofwork hash.
Click to expand...

I was wondering about how secure this was. Although I realise that the selection algorithm makes it near impossible for me to attack any transaction in particular, what about the converse situation ? i.e. no transaction in particular ?

Say I compiled my own 10 masternodes from source, and modified their processing logic. Then collateralised them and simply waited for those ten to be picked which must be a statistical certainty after a certain number of weeks, months or years.

What type of damage could I do ? I'm not just talking about affecting a single transaction but more of damaging confidence in the network generally by demonstrating that I managed to take control of an entire quorum.

What I'm pointing out - as far as I understand - is that the deterministic algo for quorum selection is only deterministic for a GIVEN TRANSACTION. It doesn't stop people from predicting that a particular 10 nodes will form a quorum at some point and using that fact to design some malicious collusion logic in a kind of "quorum landmine" attack.
 
Last edited:
I can see one defence against this type of attack. It's clear that a masternode which forms part of a potential landmine quorum must never be able to know whether the whole set of bad nodes has been selected or not. That way it can't know when to optimally mount the attack (by executing 'bad quorum logic' instead of 'good logic').

The landmine would therefore have to be always active or always inactive and its members would presumably quickly reveal themselves to the network and be excluded from decision making. However to complete the cover, I imagine the network should have some kind of holistic learning which works over time to make sure that bad actors in any one transaction are identified as potential quorum landmine members and that such nodes are never selected together to make up a whole quorum.

Is it the case already that a given node cannot know who the other nodes are that are involved in 'group signing' duties ?
 
Last edited:
I'm not sure, I think Evan came up with yet another way to choose the MNs, but for that very reason, earlier, he came up with splitting the age of the MNs into 3 or 4. Earliest, middles and latest, based on when the MNs received their 1000 coin deposit. A masternode owner would have to have 10 masternodes that he set up in all of these periods of time, and yet the separation lines between them will change as the numbers change and as MNs change hands. Thus, one could never go back in time to buy a MN to fill that earlier slot. And if someone sold their MN, and the buyer leaves it in that same state, they will risk that the previous owner will steal those coins as they once had access to the private keys. So that would be rather silly.

I thought this was quite brilliant. But even if the statistics say you'll control all 10 in a single quorum one day, you also have to know when it happens.
 
TanteStefana said:
even if the statistics say you'll control all 10 in a single quorum one day, you also have to know when it happens.
Click to expand...

I think this is the key point - whether it's possible for group to act coherently and execute logic that would be inconsistent with the rest of the network (since the rest of the network is excluded from the quorum consensus).

I remember the age splitting thing coming up in discussions but wasn't sure what that was all about at the time. Now that I've started to think about this I understand it more and it is indeed a great security enhancement. It might be rendered useless though if there's a lot of capacity demand and a low age distribution of collateral addresses. I think the assumption has to be made that the landmine quorum exists at all times and will get "stepped on" eventually. The question is, what's the maximum damage it can do.
 
Last edited:
Here's another way of looking at it.

In a cryptocurrency network, at any given moment, the network may be heterogeneous with regards to node logic. For example, right now, some part of the bitcoin network is running Bitcoin XT (about 600 nodes) and the rest isn't. Since the output of the XT nodes is consistent with that of the non-XT nodes, they are transparent at the moment.

But what happens if some of the network is "rogue" and produces output that's inconsistent with the rest ? The chain forks, and the longest chain continues. So the majority is always acting to subvert minorities.

However, now consider if the Bitcoin network was using quorums to execute additional tier-2 logic. In this case the minority XT nodes WOULD be having an effect by now - at least on individual quorum actions - because it's likely that very occasional randomly picked quorums of 10 could have a majority of XT nodes and therefore execute an alternative quorum logic to what the network majority is running.
 
Last edited:
Sorry to keep replying to my own posts but thought I'd better update my thoughts just for the record.

I just realised that the previous remarks about network majority rule and longest chain apply specifically to the mining software and mining logic. However here we're talking about nodes - and in this particular case, a subset of incentivised nodes. So achieving a reasonable level of network homogeneity might not be as big a challenge as I thought but still I think the "landmine" attack needs to be thought deeply about.

I suddenly feel a bit more optimistic about the quorum approach but the question is, why didn't anyone point this out to me earlier ?

A. Because no-one's reading this thread. They're all far more interested in the Dailydecrypt format, Amazon's cool videos and Tante's sketches.
Q. Yes they are - it's got 95 views.
A. No. That's just you checking back every 10 minutes for replies

Ok then. I'll leave it alone for a while now that I've aired my concerns and wait and see what comes out of the prototypes.
 
omg, omg!!! toknormal is posting in dashtalk!!!! :smile::smile::smile: glad to see you around my friend!

If I'm not mistaken, what you are saying is that we should have a signalling mechanism to detect rogue masternodes and not include the in quorums once they misbehave. This way someone with a few rogue masternodes would not be able to subvert the system by controlling all masternodes in a quorum because they would stop being eligible long before statistics gave him a chance.

I think you are right, the effect of someone controlling one quorum would be really bad. I guess some kind of protection could be included, but that goes over my paygrade :smile:

Anyway, I just calculated the probability of someone with 10 rogue masternodes of controlling a quorum when there are 3400 masternodes in the network and it is 1,78125968492361E-029

That is one in something some big I don't know how to call it. Acording to wikipedia (https://en.wikipedia.org/wiki/Names_of_large_numbers), 10^30 is called a nonillion, so I guess that is the closest approximation: one in a nonillion :cool:.

With those numbers it is not a matter of years or decades to get a hit, we all will die long before that number of blocks. And that would assume that you have the masternodes with the right ages, as TanteStefana explained. Of course, things improve with more masternodes, but not fast enough. For 100 masternodes the probability still is 3,08341563683086E-016 (somewhere between quadrillion and quintillion).
 
Hi Fernando

Yes - I'm posting here :-). I do from time to time actually, it's just that on the more controversial stuff I feel like I'm preaching to the converted if I post here but at the same time I always forget how busy this place is.

Interesting probability calculation. Are you sure that's the result ?

I'm a bit time restricted now but will look into this and post back.

Thanks for the reply in the meantime !
 
toknormal said:
Hi Fernando

Yes - I'm posting here :-). I do from time to time actually, it's just that on the more controversial stuff I feel like I'm preaching to the converted if I post here but at the same time I always forget how busy this place is.

Interesting probability calculation. Are you sure that's the result ?

I'm a bit time restricted now but will look into this and post back.

Thanks for the reply in the meantime !
Click to expand...
I know you like the war at btctalk :smile:

Here you have the calculations for the probability:
https://docs.google.com/spreadsheets/d/1bfbdbYFA0VyK_znasw6y8qMGVElmBOa_PCzBr5BNMvY/edit?usp=sharing

I think it checks, but second set of eyes always helps! basically it is the probability of one selected, multiplied by the probability of a second one selected, and so on...
 
Fernando it seems you are right - at least in principle regarding the small probability.

As far as I can see, the probability of a particular group of nodes being selected for "quorum duty" is obtained by dividing the frequency of occurrences of a particular quorum set by the total sample space.

If I'm correct, the frequency is simply the factorial of the quorum size = Q!
The sample space can be calculated from the binomial coefficient of 2 numbers: the masternode population (Mp) and the quorum size = C(Mp,Q)

So the probability = Q! / C(Mp,Q)

For Mp=3500 and Q=10, that results in:

Q! = 3E6
C(Mp,Q) = 7.5E28

Which makes the overall probability of a particular set of 10 around 1 E-21. A bit higher than what Fernando calculated but still infinitesimally small.

Despite that, I think it's still important due diligence to calculate the edge cases - e.g. 2 in particular spring to mind:

[1] - how does the case of a single holder of 500 masternodes shift the result in their favour
[2] - how does compromising on quorum unanimity shift the odds (e.g. if only 6 out of 10 quorum members are needed to force an action then that increases the odds in the hackers favour)

Then a final bit of due diligence would be:

[3] - if, in the unlikely event a quorum landed on a perfect 10 of "hacked nodes", what maximum damage could it do ?

I think this should all be worked out by someone who knows what they're doing in this area and properly explored (before some hacker works it out for us). The reason I think this is that quorums is a groundbreaking concept in cryptocurrency. Cryptocurrency networks are based on majorities running the show, not minorities. They therefore cater for heterogeneous networks and don't depend on homogeneity. (As we see with Bitcoin and XT nodes). If Dash is going to turn this principle on its head - albeit only for the second logic tier - it should do so with its eyes open, not closed.

P.S. Some handy references:
https://en.wikipedia.org/wiki/Sample_space
https://en.wikipedia.org/wiki/Binomial_coefficient
https://en.wikipedia.org/wiki/Poker_probability#anyfive
http://www.ohrt.com/odds/binomial.php
 
I fully agree with you that we should do further research into this! I think I can set it up and engage a dev for the parts that are magic to me :smile:

I'll look into your way of calculating the probability to understand why we get that difference. It will take me a few days, though. Today I'm quite busy and tomorrow I'm leaving for my postponed christmas vacation :cool:
 
The difference might be because your method calculates the probability of a particular sequence of the 10 instead of any sequence (There are 10! ways that the 10 could be chosen).
 
I believe I'm calculating it that way. I calculate the probability of the first one as #rogueMasternodes / #totalMasternodes, which is 10/3400. The second would be 9/3399, and so on. I multiply the probabilities of all events, so I have the 10! in the numerator.

Anyway, I'll check in a few days, I'm going on vacation now :cool::cool::cool:
 
Guys, if masternode quorums are going to get more options to do than ever before, will there be some way to auto-corect bad decisions when attack happened?

There might be some vulnerability in code of client or some linux vulnerability or anything, so there are many other vectors that could shake with concepts of dash security.

I like this security model, but in bitcoin, you have blockchain and bad blockchain lose, how will hackers lose in this system?
 
You must log in or register to reply here.
Back
Top