This would ensure that a fork is transparent to the end-user. The user should not be forced to choose which network to use as it could lead to confusion among users who do not care about developer drama. To ensure that pre-fork coins are recorded on both forks, a rule should be introduced that prevents users from "tainting" their pre-fork-mined coins with coins mined after the fork. This setup encourages the minority chain to die, and unity returned. However, if pre-fork coins change hands on either fork (and not on the other), then holders have an incentive to not let their chain die, and the networks will be irreversibly split forever.The proposed Bitcoin transaction format involves a network characteristic byte interpreted as a bit vector where up to 8 networks share a common history. Rules in the new network include that if the network characteristic byte is non-zero and the new network characteristic bit is not set, then the transaction is invalid (softfork). If the network characteristic byte is zero, go to rule 4. If the network characteristic byte is non-zero, and the new network characteristic bit is set, go to rule 4 regardless of the status of the other bits. If the masked version is 2 or below, there is no change; 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 (hardfork).Rules in the existing network include that there are no consensus rule changes made in the existing network. If the network characteristic byte is non-zero and the existing network characteristic bit is not set, this transaction is not relayed nor mined by default. If the network characteristic byte is zero, there is no change. If the network characteristic byte is non-zero and the existing network characteristic bit is set, the masked version is used to determine whether a transaction should be mined or relayed.The proposal is constrained by the requirement of backward compatibility. Transactions created before this proposal is made are not protected from anti-replay. The new fork has to accept these transactions since there is no guarantee that the existing fork would survive nor maintain any value. To maximize the value of such transactions, the only way is to make them accepted by any potential hardforks. It doesn’t require any consensus changes in the existing network to avoid unnecessary debate. Rationales behind these rules include making sure transactions with only existing network characteristic bit set are invalid in the new network (opt-in anti-replay for existing network transactions on the new network, objective A), making sure time-locked transactions made before this proposal are valid in the new network (objective B), preparing for the next hardfork from the new network (objective A), minimizing changes to the existing network (objective C), and anticipating a hardfork (objective A). Limitations of this proposal include that it is not possible to protect transactions made before the proposal, that it is up to the designer of a hardfork to decide whether this proposal is respected, and that the size of network characteristic byte is limited to 8 bits. A demo for this proposal is available in the forcenet2 branch on GitHub.