Quote from: MentalCollatz on July 11, 2015, 08:32:58 AM

Quote from: HR on July 10, 2015, 01:58:20 PM

...snip...

Of course, everything I'm saying is just off the top of my head, but without any serious statistical analysis on the part of those that say this is a reality - a 51% attack with less than 51%, or even with 61%, as has been said here - what I'm saying holds the same weight (if not more since common sense tells us that less than half is not equal to half).

Common sense tells us that a 51% attack requires a 51% control of the ENTIRE network, not 51% of 20% of the network, unless you're able to stop the other 4 algos from discovering new blocks over a short period of time, something which no-one has ever said is possible (will this be the next shoe to drop?) and something that doesn't happen regardless of how much one individual algo's hashrate spikes.

...snip...

This made me laugh - especially the part about what you're saying holding even more weight because it's based on "common sense". No offense, but no amount of "common sense" can match up to having read (and written parts of) the source code. Let me do my best to break it down:

If you mine a block using SHA256d at difficulty 1000000, the network says this block contains 1000000 "work units".
If you mine a block using Scrypt at difficulty 30, the network says this block contains about 120000 "work units".
If you mine a block using Groestl at difficulty 200, the network says this block contains about 100000 "work units".
If you mine a block using Skein at difficulty 1000, the network says this block contains 24000 "work units".
If you mine a block using Qubit at difficulty 40, the network says this block contains about 40000 "work units".

If one block of each algo is mined every 150 seconds on average, this amounts to 8560 "work units" per second by the main network.

Now consider an attacker with enough hashpower to maintain the SHA256d difficulty at 1300000 (without the rest of the network). At one block every 150 seconds this amounts to 8666 "work units" per second. Therefore, the attacker can produce "work units" at a faster rate than the main network, and use this to mount a 51% attack against the coin.

So what about the one-cpu attack? Well, at the time Myriad was taking the sum of the difficulties (without the multipliers) as the "work units". In the above example each block would contain 1001270 "work units", regardless of which algorithm was used. The attacker chooses a starting point for his chain when the SHA256d difficulty is high, and because he doesn't mine SHA256d the difficulty for that algo doesn't change. Eventually, the attacker's blocks have difficulties that look something like (1500000, 1, 1, 1, 1) and generate 1500004 "work units" per block, despite the attacker actually mining at difficulty 1. The dev team fixed it by adding a decay step to the work calculation - if too many blocks go by without a particular algorithm finding a block, the "work units" provided by that algorithm are reduced (possibly all the way to 0). But Myriad is still vulnerable if the attacker has slightly more than 50% of the SHA256d hashrate.

So how do we solve it? In the DigiSpeed branch, "work units" are calculated by multiplying all of the difficulties, then taking the 5th root. For the example difficulties at the top of this post, it works out to about 750 "work units" per block. But if an attacker has enough hashpower to maintain the difficulties at (9000000, 15, 100, 500, 20), his blocks contain only 670 "work units" each, even though he controls 90% of one algorithm and 33% of the other 4 algorithms. Note that pre-DigiSpeed "work units" are not directly comparable to post-DigiSpeed "work units", and the code contains a fudge factor to make sure the coin isn't vulnerable during the transition.

Now that's what I mean by making an argument based on hard data, and just in time!

Why is it that it's like pulling teeth to get people in cryptocurrencies to document what they're talking about? Why is it that it takes so much nudging to get this kind of info clearly published? Why is it that devs think the rest of the world should just trust them?

You know what? If that had been said a month ago, it might have gone a long ways towards supporting price since it would have been seen as a proactive announcement back then. Now, coming on the heels of all the prodding that was necessary to get a straight answer, it's actually no longer a positive, and can even be seen as a negative for dragging your feet and coming straight only when there was no other option. The potential investor will ask, "if this is their modus operandi, what will they do in the future?"

Anyhow, that's a very nice start at an in-depth explanation regarding this particular issue and for what's being done. Now let's see what more might be in store for the other burning issues of the day.

Life is all about making good decisions. I encourage all of you to reflect on that basic fact and on how you might improve on your decision making and communication.

BTW, the "common sense" bit was so absurd that it was assumed to be automatically interpreted as a tongue-in-cheek prodding joke, as in "this is so ridiculous that . . ." in the hopes of finally getting something serious in return. Looks like it worked, but as I've just said, it shouldn't be necessary and the fact that it is necessary is very detrimental to DGB.