But the headline says that this exploit is already in the system since before and devs js just hiding it, sort of. Is that true?
the exploit has existed since the blockstream devs re-wrote the bitcoin codebase to be including certain features and what they believed were certain optimisations (from 0.14.x)
bitcoin nodes that did not include those certain features are immune automatically from having themselves become victim of becoming DDosed.
but while nodes that are immune wont get DDoSed by a malicious block. the network, while it continues to have a mix of vulnerable nodes could see a chain of blocks broadcast to it containing the malicious block and see it get rejected and cause havok with transaction confirmations
EG
imagine a chain of 5 blocks
block height X12347
block height X12346
block height X12345
block height X12344
block height X12343
imagine x12343 was a malicious block exploiting the bug
the network of immune nodes reject it. and accept a different pools y12343
there are now 2 block height of 12343 (x and y)
the immune nodes add a clean y12344 to their clean y12343 and life goes on. y..5 y..6
but behind the scenes the malicious pool adds on a x..4 of their own to their bad x..3.. and then a x..5 and then a x..6
now imagine that the malicious pool gets to add on a x..7 before the clean pools win the block creation race
the malicious node announces they are the winner. broadcasts its CLEAN x...7 and all nodes see its good.
the immune nodes then because this winner has differing y..6 y..5 y..4 y..3 request the 4 differeing blocks the immune nodes dont have.
and
optimised check x..3 is good. keep it and delete their y..3 <- important point. ill explain in next post
and optimised check x..4 is good. keep it and delete their y..4
and optimised check x..5 is good. keep it and delete their y..5
and optimised check x..6 is good. keep it and delete their y..6
and optimised check x..7 is good. keep it.. now all caught up
so now they have seen transactions in Y that had upto 7 confirms that are now gone
and now can see transactions in X that have upto 7 confirmations suddenly show as confirmed
now the immune node thinks it has caught up, it can regenerate a new set of the confirmed transactions which requires a full check of the blocks (unoptimised)
and bam.. x..3 is show to be bad. <- important point. ill explain in next post
meaning x..4 5 6 7 are also bad.
suddenly the x blocks are rejected and the transactions are unconfirmed.
and the immune nodes ban any conversation with nodes broadcasting a x chain.
the immune nodes then rebuild the y chain. and suddenly the transactions in the y chain re appear as confirmed again.
...
this game can continue every new block the x pool wins the fastest block race. of making confirms disappear and reappear. until the entire network either
a. outpaces the x pool to never win a block again
b. the entire network bans communication with vulnerable nodes broadcasting x (causing a altcoin fork)
c. there are no more nodes or pools that accept/create/rebroadcast x blocks
which is a case where a solution is usually found and implemented within 200confirms, as having x continually disrupt and causing a headache of rejections wont get tolerated
in simple terms
if some people keep gifting you the same crappy (10min)birthday present, within 200 birthdays you will stop inviting them to your party(option b)