A replay attack occurs when a transaction is replayed on another network, potentially causing unintended consequences. To prevent this, the proposal suggests implementing anti-replay protection as an optional feature for users on both the existing and new forks.Transactions created before the proposal was made are not protected from anti-replay, as there is no guarantee that the existing fork will survive or retain any value. However, the new fork must accept these transactions. The proposal does not require any consensus changes in the existing network to avoid unnecessary debates.In addition to preventing replay attacks, the proposal also offers a beneficial side effect of fixing a signature checking bug for non-segregated witness inputs. The rules outlined in the proposal ensure that transactions with only the existing network characteristic bit set are invalid in the new network. Time-locked transactions made before the proposal are considered valid in the new network. Conversely, transactions specifically created for the new network are invalid in the existing network.To avoid a replay of such transactions, users should first spend at least one relevant UTXO on the new network, which would invalidate the replay transaction. It is ultimately up to the designer of a hardfork to decide whether or not to implement this proposal.The size of the network characteristic byte is limited to 8 bits, but if certain networks are completely abandoned, the bits may be reused. A demo of the proposal can be found in the forcenet2 branch on GitHub. The proposal should be taken into account when creating hardfork proposals, except for trivial and uncontroversial ones.In an email exchange, Johnson Lau pointed out the difference between an opt-out system and an opt-in system. He argues that an opt-in system would require unmodified yet compatible systems to change in order to support the new network, which is self-defeating. Lau suggests that an opt-out system would make more sense for everyone involved.In another email exchange, the question of whether Alice is protected in a hardfork scenario is discussed. Lau proposes a scenario where Alice pays Bob with an old-style time-locked transaction, and after the hardfork, Bob can confirm the transaction on both networks. However, if Alice has full control, she is already protected by a proposal that does not require any protecting child transactions. If the time-locked transaction is unprotected in a 2-of-2 multisig where Bob receives the payment, Bob will receive all the money from both forks without renegotiation with Alice.In a different email discussion, Lau questions a proposal regarding the replay protection of Bitcoin transactions after a hardfork. He argues that Alice would not hold onto an old-style time-locked transaction if she doesn't control any of the UTXOs and cannot substitute the transaction for one where she does have control. Lau suggests that Bob could still confirm the time-locked transaction on both networks after the hardfork by sending the outputs to himself again with a different transaction format, making it a successful replay.In a separate conversation between Tom Harding and Johnson Lau, they discuss proposals to prevent transaction replay attacks in the event of a chain split. Lau's proposal is an opt-in approach, while Harding suggests a soft fork that supports its own hard-fork opt-out bit. They also discuss the specific changes suggested by Lau's BIP and the need for consensus changes in the existing network. They agree that their proposals are similar but differ in their approach.Overall, the proposal aims to resolve the issue of replay attacks during a blockchain split by implementing optional anti-replay protection and introducing rules for both the existing and new networks. It is important to consider this proposal when creating hardfork proposals to ensure the safety and integrity of transactions.