I don't get much either but since this is a critical vulnerability, devs would solve it asap, so certainly it won't be an 'end'.

Thank you for the simple and newbie-friendly explanation.I hope that more newbies will read it.
Anyway,Bitcoin Core is updated and that bug won't be a threat for the blockchain anymore.
I wonder,I would've happened,if most of the miners started expoiting that bug.Will this lead to a major bitcoin price crash?

some nodes have a checkpoint of 200 confirms that lock a chains state as immutible. meaning anything less than 200 confirms if something was off about that block is able to be rejected and its subsequent blocks of that 'iffy' chain can be rejected.

many people state this bug is 'fixed' for the network. however. the real wording is that a vaccine has been provided for the vulnerable (nodes based on core 0.14.x-0.16.2 code) and it still requires everyone who is not already immune via having a diversified codebase (not core 0.14.x-0.16.2) to upgrade, so that there are no more (core 0.14.x-0.16.2) vulnerable nodes left on the network

until the point of which the network has removed the vulnerable nodes, there is still some risk. especially for those running such

many people also think that the mining reward is a defense in itself to not try it. however trying to assume that miners wont do something because of a 12.5 reward is flawed.

there are over 20 pools and only 1 pool gets the 12.5btc every ~10 minutes.
the other pools still mine blocks knowing that its not a guaranteed outcome of every pool wins. but a fight.
they still mine anyway.

knowing on average across the network its a 95% chance they can make a block, work on it and not get 12.5 anyway. every 10 minutes they continue working anyway. so a malicious pool could take the risk... because they are used to not always getting 12.5btc every 10 minutes anyway.. thus its not really a loss if they dont get it. they will just try it, and worry about getting income in later blocks

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)

the  "<- important point" in my last post

the optimisation bug. was that it does not check for duplicate inputs in the initial 'optimised check' of a block. but does check when the node thinks its download new block sequence is done and can rest for a few moments.

so there is a gap in time where a transaction can reuse a input of funds of say xbtc hundreds of times in a block and it show as confirmed at the first important point. but rejected at the second important point

usually all of this happens in a few seconds. but some people may have systems inplace that if they see something have a confirm. that instant they authorise some goods to be delivered or a service to be honours.

 

look into orphans/rejects

transactions are deemed as 'confirmed' but not 100% immutible..as that takes time..
it just means it passed the first quality assurance checks, but thats not all of the checks/risks covered/ruled out

bugs can make blocks get rejected, thrown away and thus the transactions of that block are not part of the chain anymore. thus no confirms no existance. and not immutible.

once all the FULL checks are done
once enough good blocks are added to good blocks the chances of a transaction in the past being of issues becomes nothing.
(more blocks=more confirms=more confidence= eventually milestoned as immutable.. eventually(not instantly at 1 confirm))

its why some say dont trust a 1 confirm transaction as solid/definite as there is a 0.5% chance the block containing it can be rejected
its why some say dont trust a 2 confirm transaction as there is a 0.0025% chance the block containing it can be rejected
and so on

so only risk instantly accepting  (during a no known bug period)
a value of ~chewing gum for 0 confirms
a value of ~ a meal for 1confirm
a value of ~ a weeks salary for 2 confirms
a value of ~ a second hand car for 3 confirms
a value of ~ a lambo for 4 confirms
a value of ~ a house for 5 confirms
a value of anything for 6 confirms

but because of the bug. treat 200 confirms as the milestone as orphans/rejects can keep happening. for upto a day until the network cannot tolerate/allow constant interruptions of orphans/rejects