summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGavin Andresen <gavinandresen@gmail.com>2016-02-12 17:33:52 -0500
committerGavin Andresen <gavinandresen@gmail.com>2016-02-12 17:33:52 -0500
commit1b9cab75a993fe27b1851df36087d7a9f1043be8 (patch)
tree764b944f892ed02c16a52f3043af856e7cd98266
parent0c7b56c823e96906fa75fa17726470b51c2c88c7 (diff)
parent0c0ac09ccf8586335ea93cd1d0ae550862a370e4 (diff)
downloadbips-1b9cab75a993fe27b1851df36087d7a9f1043be8.tar.xz
Merge pull request #327 from btcdrak/patch-3
Correct typo
-rw-r--r--bip-0050.mediawiki2
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.