Skip to content

Instantly share code, notes, and snippets.

@gavinandresen

gavinandresen/postforkplan.md

Last active July 31, 2021 02:52
Show Gist options
  • Save gavinandresen/5170684 to your computer and use it in GitHub Desktop.
Save gavinandresen/5170684 to your computer and use it in GitHub Desktop.
Download ZIP
Post chain fork short-term plan
Raw
postforkplan.md

What we know:

  • the fork was caused by a block that needed over 10,000 BDB locks to be confirmed
  • A conservative estimate of the number of locks needed to confirm a block is: (#unique txids referenced)*2.03 + 100, where unique txids referenced is number of transactions created in the block plus the number of previous transactions referenced by those transaction's inputs
  • A majority of hashing power was running version 0.8, and most miners are motivated to upgrade
  • BDB lock settings can be configured at runtime, by putting a file called DB_CONFIG in the data directory. DB_CONFIG overrides compiled-in settings.
  • Chain re-orgs can also trip the "too many locks" problem, depending on how many unique txids are involved. Since transactions tend to overlap between chains during a re-org, this is not as large a problem as one might think.
  • We would have a problem even if the network was all 0.7 nodes, because 0.7 could theoretically "self-fork" : the exact number of locks taken depends on the blkindex.dat file, which depends on what orphan blocks have been seen, in what order, etc.

What we want short-term:

All miners and merchants and users to either upgrade to 0.8 or set DB_CONFIG and configure for 50,000 locks.

TODO list:

Release a 0.8.1 that, for the next 2 months, has the following restrictions/rules:

  1. Reject blocks where (#unique txids referenced)*2.03 + 100 > 10,000
  2. Limit maxblocksize (maximum size of blocks created) to 500,000 bytes

Release a patch for releases < 0.8 that:

  1. For the next 2 months: rejects blocks where (#unique txids referenced)*2.03 + 100 > 10,000
  2. Increases locks to 50,000

Create a web page for releases < 0.8 on bitcoin.org that:

  1. Urges people to upgrade to 0.8.1
  2. Gives instructions for setting DB_CONFIG if they absolutely cannot upgrade

Send alerts to < 0.8 as the 2-month deadline to upgrade/fix approaches:

  1. "Now" : 24-hour alert, pointing to web page
  2. One month before deadline: another 24-hour alert
  3. One week before deadline: final alert that "never" expires
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment