bitcoin-dev
Anti-transaction replay in a hardfork
Posted on: January 24, 2017 18:52 UTC
On 24th January 2017, Johnson Lau sent an email to bitcoin-dev regarding the use of a masked version in determining whether a transaction should be mined or relayed.
The proposal supports 8 opt-out bits compatible with many earlier descriptions. If the existing network wants to support its own hard-fork opt-out bit, it should execute a soft fork as soon as possible. It is inadequate for a new network to rely on non-standardness in the existing network to prevent replay there. A responsible new network would allow something that is invalid in the existing network if replay to the existing network is undesirable. Johnson's BIP suggesting specific changes to be included in the new network is an overreach as it is a matter for the new network itself. The proposal suggests implementing a specific O(n^2) fix, which is not necessary.