Published on: 2011-10-03T05:39:07+00:00
In an email conversation on October 3, 2011, Luke-Jr proposed two safeguards for a new rule implementation. The first safeguard, option (3), suggested that before applying the new rule, 50% of the last Y blocks should contain a coinbase with an "I am upgraded" code. However, this option was not as desirable because it assumed that 95% of the network is neutral regarding the change. The second safeguard, option (4), proposed adding an "I am upgraded" code in every block until the new rule is active and then turning it off afterwards. This option was well-received and had added benefits since it served as proof in determining the likelihood of a fork of length X if a newly invalid transaction is announced during activation.On the same day, Gregory Maxwell presented a plan for upgrading nodes which included several rules. The first rule stated that transactions invalid under the new rule should never be forwarded or mined. The second rule required the old behavior to be applied unconditionally before height X, where X was set far enough in the future to ensure reasonable deployment by large miners. The third rule mandated that 50% of the last Y blocks must contain a coinbase with an "I am upgraded" code before the new rule could be applied. The fourth rule specified that until the new rule is active, every block should contain an "I am upgraded" code. It was suggested that members of the bitcoin community intentionally transmit transactions that are invalid under the new rules once the software has been released, as a safeguard against possible attacks.The addition of the eval opcode could potentially make previously valid transactions invalid without causing lasting chain splits. However, if invalid transactions are emitted after the block height at which the new rule is set to take effect and a super-majority of miners have not yet upgraded, there may be a long reorganization and serious disruption. To avoid this, upgraded nodes should follow certain rules, such as not forwarding or mining invalid transactions and applying the old behavior before height X unconditionally. The new rule should only be applied after a point in the chain after X when none of the last Y blocks have contained an invalid transaction under the new rules.Once the software has been released, members of the bitcoin community can intentionally transmit transactions that are invalid under the new rules. By setting Y high enough to allow all major miners to mine in the window, this becomes an effective vote for the change by miners with a stochastic super-majority threshold. All nodes can accurately determine at what block the election has completed because it is an objective fact of the chain. This scheme ensures that the new encoding will only become active when enough mining capacity supports it, preventing large reorganizations due to incompatible blocks during deployment. Although conflicting block discouragement could further enhance this scheme, the current proposal is sufficient and generally superior for its purpose.
Updated on: 2023-08-01T02:32:01.141600+00:00