The DAO hard fork of Ethereum demonstrated that without precaution against transaction replay attacks, significant financial loss for some users could occur. A replay attack is an attempt to replay a transaction of one network on another network, which is normally impossible between different networks as they have completely different ledgers. In a blockchain split, however, since both forks share the same historical ledger, replay attacks can occur unless precautions are taken. One proposal to overcome this problem is to create a "bridge" that replays all transactions from one network over to the other and vice-versa. Forcing the user to choose which network to use is bad as it would confuse 99% of people who use bitcoin and don't care about developer drama. When a user moves coins mined before the fork date, both blockchains should record that transaction. Pre-fork mined coins should "belong" to the network with hashpower majority. No other networks should be able to claim pre-forked coins as being part of their issuance.The advantage of pre-fork coins being recorded on both forks is that if one fork goes extinct, no one loses any money. This setup encourages the minority chain to die, and unity to return. Technical issues arise when both forks are decentralized mining, and these issues are not solvable. The proposal to prevent replay attack is compared to repairing a flying plane and is constrained by the requirement of backward compatibility.The proposal aims to make anti-replay an option, not mandatory for users on both existing and new fork. Transactions created before this proposal are unprotected from anti-replay and must be accepted by any potential hardforks to maximize their value. No consensus changes are required in the existing network to avoid unnecessary debate. As a beneficial side effect, the O(n^2) signature checking bug could be fixed for non-segregated witness inputs optionally.Rules in the new network include that if the network characteristic byte is non-zero, and the new network characteristic bit is not set, the transaction is invalid in the new network (softfork). If the masked version is 2 or below, the new network must verify the transaction with the existing script rules. If the masked version is 3 or above, the new network must verify the signatures with a new SignatureHash algorithm. Rules in the existing network state that no consensus rule changes are made, and if the network characteristic byte is non-zero, and the existing network characteristic bit is not set, the transaction is not relayed nor mined by default. Wallet may provide an option for setting the existing network characteristic bit.Limitations of the proposal include that transactions made before the proposal cannot be protected, and users should spend at least a relevant UTXO on the new network to invalidate replay transactions. It is up to the designer of a hardfork to decide whether this proposal is respected, and the size of the network characteristic byte is limited to 8 bits. A demo of the reference implementation is available.