Usually there is an assumption, that a transaction is fully finalized after 6 confirmations, e.g. 6 blocks mined on top of the block, which includes given transaction.
What is the length of largest known reorganization in bitcoin?
0
Add a comment
|
1 Answer
There have been only two large re-orgs in Bitcoin's history. The first is the value overflow incident in August 2010 that caused a re-org of 53 blocks and the March 12, 2013 fork that caused a re-org of 24 blocks.
Value Overflow Bug
On August 15 2010, it was discovered that block 74,638 contained a transaction that created 184.4 billion bitcoins for three different addresses. Two addresses received 92.2 billion bitcoins each. Yes you read that right. 184.4 billion Bitcoins!!! This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed.
Integer overflow is the digital equivalent of a mechanical odometer wrapping around to zero after a car drives 999,999km. The overflow caused the software to think that the transaction contained only a small amount of BTC while in reality the outputs of the transaction together had thousands of times more than the 21 million that should ever exist.
Satoshi published a new version of the client within five hours of the discovery. This release contained a soft forking change to the consensus rules that rejected the output value overflow transactions (as well as any transaction that paid more than 21 million bitcoins in an output for any reason).
Although many unpatched nodes continued to build on the "bad" blockchain, the "good" blockchain overtook it at a block height of 74,691 at which point all nodes accepted the "good" blockchain as the authoritative source of Bitcoin transaction history.
March 2013 Chain Fork
The v0.8 release of Bitcoin Core switched the database that it used to store blocks and transactions from BerkeleyDB to LevelDB as part of an effort to reduce blockchain synchronization time. A bitcoin miner running v0.8 created a "large" block (at height 225,430) that was incompatible with earlier versions of Bitcoin leading to the Bitcoin blockchain splitting into two, with one half of the network adding blocks to one version of the chain, and the other half adding to the other.
In order to make an update to a database, the program must make a “lock” on the part of the database which stores that particular item of information. This mechanism is implemented to prevent two changes from occurring simultaneously and accidentally corrupting the database.
In a b-tree, the data structure used by BerkeleyDB to store objects, two locks are required per update. However, BerkeleyDB requires its users to set a limit to the number of locks that can be made at the same time. If the values are too small, requests for locks in an application will fail. If the values are too large, the locking subsystem will consume more resources than is necessary.
In the case of Bitcoin, this limit was 10,000. What happened in block 225,430 was that a single block simultaneously affected the status of over 5,000 transactions, thereby requiring more than 10,000 locks on the b-tree to be made at the same time. As a result, BDB failed, and so the older (v0.7 and earlier versions) could not read the block. In the case of v0.8, LevelDB has no such restrictions, so it could accept such blocks just fine.
It was finally resolved by miners downgrading their Bitcoin Core to v0.7. This placed majority hashpower on the chain without the "larger" block, thus eventually causing the v0.8 nodes to reorganize to the v0.7 chain.
answered Jan 26, 2020 at 13:31
