Author: Mark Friedenbach 2013-03-13 17:41:29
Published on: 2013-03-13T17:41:29+00:00
In this email thread, members of the Bitcoin-development mailing list are discussing a proposal to handle a crisis without resorting to a hard fork. The proposal includes patching pre-0.8 branches to support an increased lock count, not generating blocks which trigger the lock count limit, and providing a non-standard patch to mining pool operators rejecting blocks that trigger the lock count limit. At some point in the future, once there is widespread adoption of patched clients, miners would remove the patch in a coordinated way. Additionally, Luke-Jr proposes a solution involving block size limits and soft and hard forks that take place at certain block numbers. Before block 262144, blocks should never result in over 4500 transaction modifications and reject any block with more than 4500 transaction modifications on its own. From block 262144 to block 393216, blocks should not include more than 24391 transaction modifications on its own, and from block 393216 onward, blocks should not include more than 48781 transaction modifications on its own, with acceptance of blocks up to 2 MB in data size and discontinuation of support for clients prior to 0.8.1.
Updated on: 2023-06-06T10:58:14.158089+00:00