diff options
Diffstat (limited to 'bip-0050.mediawiki')
| -rw-r--r-- | bip-0050.mediawiki | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki index dbec7aa..fbc1c0f 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -2,7 +2,7 @@ BIP: 50 Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen <gavinandresen@gmail.com> - Status: Draft + Status: Final Type: Informational Created: 2013-03-20 </pre> @@ -30,7 +30,7 @@ With the insufficiently high BDB lock configuration, it implicitly had become a Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident. -Bitcoin Core 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully. +Bitcoin 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully. Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs. |