diff options
| author | ฿tcDrak <btcdrak@users.noreply.github.com> | 2016-02-10 17:25:52 +0000 |
|---|---|---|
| committer | ฿tcDrak <btcdrak@users.noreply.github.com> | 2016-02-10 17:25:52 +0000 |
| commit | 0c0ac09ccf8586335ea93cd1d0ae550862a370e4 (patch) | |
| tree | ae51702f2e190665303a439d674baef07dd573c7 /bip-0050.mediawiki | |
| parent | e216baba46684c7e2551c6d39b9e2a848b4d6337 (diff) | |
| download | bips-0c0ac09ccf8586335ea93cd1d0ae550862a370e4.tar.xz | |
Correct typo
Bitcoin Core didn't exist until 0.9.
Diffstat (limited to 'bip-0050.mediawiki')
| -rw-r--r-- | bip-0050.mediawiki | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki index 3107070..a595321 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -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. |