Currently, an attacker can 51% attack the network with roughly 60% of SHA256D and nothing else. After this change, an attacker with 90% of the SHA256D hashrate and 33% of each of the other 4 algorithms would have insufficient hashpower to mount a 51% attack. Is this true? Source: https://github.com/digibyte/digibyte/pull/36 So in theory a attacker does not need to have some hashrate in all 5 algorithms (used in marketing of digibyte)? 60% of SHA256D is sufficient?
That's my pull request, here is an up-to-date calculation.
Based on current difficulties (averaged over 1000 blocks), this is each algorithms contribution to the work calculation:
sha256d: 1.13e+06 * 1
scrypt: 23.7 * 4096
groestl: 152 * 512
skein: 1070 * 24
qubit: 47.6 * 1024
This adds up to 1.38e6. Half the total can be made with just 61% of the sha256d contribution. Asics are to blame. When the formula was crafted, each algorithm did indeed have a near-equal contribution. But as the sha256d hashrate climbed the others couldn't keep up. It was always true that an attacker could attack the coin with just 1 algorithm but they would have needed at least 87% if all algorithms were weighted properly. The new formula does not rely on magic work factors, and does not allow one algorithm to dominate under any circumstances.
I'm not going to throw stones at marketing. As far as I can tell they didn't know it was wrong. Now we know, but already have a fix to make it even stronger than the original claims.
MentalCollatz would be the proper authority to answer this. And yes, at the time of our first hard fork to multi algo we did not know this formula was incorrect. We are always working to improve things. We have worked in his changes to the upcoming DigiSpeed hardfork that will make things much better.
Also @Mental, we would love to chat some time and run some ideas by you we have for modifying OP_RETURN. Thanks for stopping by and answering this!
Okay, Digibyte, my question is for you too so we can all understand this: what are you considering to be "work calculation"? A secondary question would be: how is that pertinent?
When looking at block discovery, all the different algos have basically the same daily average, meaning that from a "block discovery" contribution point of view, they are roughly equal. Correct, or not?
This leads to what is fundamental for a 51% attack to prosper: it needs to create a fork that essentially "pirates" the blockchain. Correct, or not?
That means that 51% of block discovery needs to be achieved. Correct, or not?
And I think that does indeed bring us back to the original calculations. Correct, or not?
BTW: An average of 1,000 is extremely small, so small as to rule out any kind of statistical validity - DGB averages just under 2,880 a day! I would recommend at least 10,000, and that with a focus on actual block discovery and the ratios you might develop from that. Would you really consider a pull request based on half a day's analysis?
(And I think that 5 times safer from a marketing standpoint is good since we're working with 5 algos - from the most simplistic theoretical vantage point, you need to gain 51% control of 5 algos instead of 1 algo, and that is 5 times safer in spite of the fact that it's not mathematically 5 times when the 5 are considered as one joint value. Correct, or not?
Also, the diff of all the algos rises and falls in correlation with one another: if the sha256d diff rises, the diff on the other 4 algos rise correspondingly. Correct, or not?)
Now, inquiring minds want to know just where the "error" is and how it really affects DGB.
