Bitcoin Forum
May 11, 2024, 06:16:42 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Aftermath of Bitcoin's 2018 inflation bug  (Read 109 times)
brainactive (OP)
Member
**
Offline Offline

Activity: 159
Merit: 72


View Profile
August 04, 2021, 12:05:20 AM
 #1

An inflation bug was discovered in 2018 which allowed some nodes to mint bitcoin out of thin air.

1) What are the impacts of this and has this compromised Bitcoin's 21 million supply?
2) Is this still a threat to the network at the moment?
3) I don't mean to be attack Bitcoin, but how is it that a bug as critical as this was discovered 10 years after launch, especially with so many developers working on the project (and bitcoin team being considered a conservative bunch that values security)?
The Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multi-signature transactions, etc. The current features of the client only hint at what will be possible in the future.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715408202
Hero Member
*
Offline Offline

Posts: 1715408202

View Profile Personal Message (Offline)

Ignore
1715408202
Reply with quote  #2

1715408202
Report to moderator
DaveF
Legendary
*
Offline Offline

Activity: 3472
Merit: 6269


Crypto Swap Exchange


View Profile WWW
August 04, 2021, 12:44:42 AM
Merited by ABCbits (1)
 #2

1) What are the impacts of this and has this compromised Bitcoin's 21 million supply?

No impact at all, no "inflation bug" coins were created.

2) Is this still a threat to the network at the moment?

No.

3) I don't mean to be attack Bitcoin, but how is it that a bug as critical as this was discovered 10 years after launch, especially with so many developers working on the project (and bitcoin team being considered a conservative bunch that values security)?

Programming errors are out there now and will always be out there. How they are handled when found is more important then the fact that they exist.
If you only want to use software without bugs, you will not use any software.

-Dave

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4172
Merit: 8419



View Profile WWW
August 04, 2021, 01:30:48 AM
Last edit: August 04, 2021, 01:41:55 AM by gmaxwell
Merited by j2002ba2 (5), ABCbits (3), Foxpup (2), HeRetiK (1), Pmalek (1)
 #3

Sounds like you might have been fed some disinformation.

Versions 0.14 to 0.16.2 had a bug where a rogue miner could have made a transaction which consumed the same input twice. But this issue was caught and rejected by the startup sanity checks.

The issue was discovered by developers and corrected in 0.16.3 and later versions.  No attack block had been created, and if one had been created before the fix was published it would have been ultimately rejected because it was caught by the startup checks and by earlier versions so ultimately the effect would have been just a very costly DOS attack by the miner.

The issue was introduced because:

The original check against duplicate inputs didn't apply to mempool transactions, so these junk transactions could end up in the mempool. To protect the mempool an additional check was added.  IIRC this would have been in 2011 or 2012.

Then in 2013, 0.8 changed block validation logic significantly and accidentally removed the block validation rule against duplicate inputs. However, this wasn't discovered even with an extraordinary amount of review and testing at the time because the "redundant" check previously added was sufficient.

Then in 0.14 the redundant check was bypassed while validating blocks to speed up block propagation and make Bitcoin able to handle larger blocks without blocks becoming stale.

Unfortunately, unknown to anyone the non-consensus "redundant" check had become critical.  While there were ample tests for double spends, they didn't happen to cover the specific conditions required to bypass the checks.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!