Author: Michael Gronager 2013-03-12 12:27:32
Published on: 2013-03-12T12:27:32+00:00
In March 2013, a Bitcoin upgrade was introduced which had an undocumented and unknown criteria for block rejection. This upgrade didn't happen fast enough and had not been sufficiently tested. The problem was not with the upgrade itself but rather with the fact that it did not happen quickly enough. The incident highlights the importance of keeping nodes up to date. Forks are caused by rejection criteria, and miners should upgrade first if new rejection criteria are introduced. If some rejection criteria is loosened, then miners should upgrade last. If the same criteria is kept, assume the second option. Regarding the block space, larger blocks may create more space for spam. While mempools are relatively small in memory usage, they do risk going up with small block sizes. In version 0.8 of Bitcoin, conflicting transactions in the chain cause clearing the mempool of conflicts, making the mempool bounded by the size of the UTXO subset being spent. Dropping transactions from the memory pool when they run out of space seems like a correct solution. A deterministic time-based rule would create a double spending incentive at that time and a counter incentive to spam the network with risky transactions. The presence of this bug, and the fact that a full solution is available (version 0.8), probably helps in achieving consensus fixing it. However, we should not rush things as a hardfork is needed. The competition for blockchain space is primarily an issue for client software which doesn't deal correctly with non-confirming transactions and misleads users.
Updated on: 2023-06-06T10:46:54.912809+00:00