Author: Jacob Eliosoff 2017-11-11 05:18:11
Published on: 2017-11-11T05:18:11+00:00
The email exchange discusses the use of nForkId, with nForkId 0 specified as the "valid on all chains" specifier. The benefits of implementing a generic replay protection scheme in advance are highlighted, as ad hoc RP schemes often break old transactions on one of the chains. However, there is a potential minor pitfall in using nForkId 0 as users must be aware that these transactions would be valid for past forks too. This could be avoided by funding from a BTC-only address, but it is difficult to find a clean way around this issue. The proposal suggests putting Bitcoin at nForkId 1, with nForkId 0 valid on all future forks. This means that a user can create an nLockTime transaction, delete the private key and still be assured not to lose potential future tokens. Additionally, nForkId 0 can be used for L2 applications where Alice and Bob open a payment channel, and project X decides to fork the network into a new token. There are four choices: ignore the new token, close the payment channel before the fork, create the commitment transactions with nForkId 0, or make the protocol aware of different nForkIds. The participants can choose to only close the payment channel on the new token after the fork, making the payment channel Bitcoin-only again. The email exchange also discusses whether the human-readable part of the standard can be used as the fork id.
Updated on: 2023-06-12T22:03:05.584785+00:00