<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is a pre-BIP. Just need some formatting to make it a formal BIP</div><div class=""><br class=""></div>Motivation:<div class=""><br class=""></div><div class="">In general, hardforks are consensus rule changes that make currently invalid transactions / blocks valid. It requires a very high degree of consensus and all economic active users migrate to the new rules at the same time. If a significant amount of users refuse to follow, a permanent ledger split may happen, as demonstrated by Ethereum (“DAO hardfork"). In the design of DAO hardfork, a permanent split was not anticipated and no precaution has been taken to protect against transaction replay attack, which led to significant financial loss for some users.</div><div class=""><br class=""></div><div class="">A replay attack is an attempt to replay a transaction of one network on another network. It is normally impossible, for example between Bitcoin and Litecoin, as different networks have completely different ledgers. The txid as SHA256 hash guarantees that replay across network is impossible. In a blockchain split, however, since both forks share the same historical ledger, replay attack would be possible, unless some precautions are taken.</div><div class=""><br class=""></div><div class="">Unfortunately, fixing problems in bitcoin is like repairing a flying plane. Preventing replay attack is constrained by the requirement of backward compatibility. This proposal has the following objectives:</div><div class=""><br class=""></div><div class="">A. For users on both existing and new fork, anti-replay is an option, not mandatory.</div><div class=""><br class=""></div><div class="">B. For transactions created before this proposal is made, they are not protected from anti-replay. The new fork has to accept these transactions, as there is no guarantee that the existing fork would survive nor maintain any value. People made time-locked transactions in anticipation that they would be accepted later. In order to maximise the value of such transactions, the only way is to make them accepted by any potential hardforks.</div><div class=""><br class=""></div><div class="">C. It doesn’t require any consensus changes in the existing network to avoid unnecessary debate.</div><div class=""><br class=""></div><div class="">D. As a beneficial side effect, the O(n^2) signature checking bug could be fixed for non-segregated witness inputs, optionally.</div><div class=""><br class=""></div><div class="">Definitions:</div><div class=""><br class=""></div><div class="">“Network characteristic byte” is the most significant byte of the nVersion field of a transaction. It is interpreted as a bit vector, and denotes up to 8 networks sharing a common history.</div><div class=""><br class=""></div><div class="">“Masked version” is the transaction nVersion with the network characteristic byte masked.</div><div class=""><br class=""></div><div class="">“Existing network” is the Bitcoin network with existing rules, before a hardfork. “New network” is the Bitcoin network with hardfork rules. (In the case of DAO hardfork, Ethereum Classic is the existing network, and the now called Ethereum is the new network)</div><div class=""><br class=""></div><div class="">“Existing network characteristic bit” is the lowest bit of network characteristic byte</div><div class=""><br class=""></div><div class="">“New network characteristic bit” is the second lowest bit of network characteristic byte</div><div class=""><br class=""></div><div class="">Rules in new network:</div><div class=""><br class=""></div><div class=""><div class="">1. If the network characteristic byte is non-zero, and the new network characteristic bit&nbsp;is not set, this transaction is invalid in the new network. (softfork)</div></div><div class=""><br class=""></div><div class="">2. If the network characteristic byte is zero, go to 4</div><div class=""><br class=""></div><div class="">3. If the network characteristic byte is non-zero, and the new network characteristic bit&nbsp;is set, go to 4, regardless of the status of the other bits.</div><div class=""><br class=""></div><div class="">4. If the masked version is 2 or below, the new network must verify the transaction with the existing script rules. (no change)</div><div class=""><br class=""></div><div class="">5. If the masked version is 3 or above, the new network must verify the signatures with a new SignatureHash algorithm (hardfork). Segwit and non-segwit txs will use the same algorithm. It is same as BIP143, except that 0x2000000 is added to the nHashType before the hash is calculated.</div><div class=""><br class=""></div><div class=""><div class="">Rules in the existing network:</div><div class=""><br class=""></div><div class="">6. No consensus rule changes is made in the existing network.</div></div><div class=""><br class=""></div><div class="">7. If the network characteristic byte is non-zero, and the existing network characteristic bit&nbsp;is not set, this transaction is not relayed nor mined by default (no change)</div><div class=""><br class=""></div><div class="">8. If the network characteristic byte is zero, no change</div><div class=""><br class=""></div><div class="">9. 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 (policy change)</div><div class=""><br class=""></div><div class="">10. Wallet may provide an option for setting the existing network characteristic bit.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Rationales (by rule number):</div><div class=""><br class=""></div><div class="">1. This makes sure transactions with only existing network characteristic bit set is invalid in the new network (opt-in anti-replay for existing network transactions on the new network, objective A)</div><div class=""><br class=""></div><div class="">2+4. This makes sure time-locked transactions made before this proposals are valid in the new network (objective B)</div><div class=""><br class=""></div><div class="">2+5. This makes sure transactions made specifically for the new network are invalid in the existing network (anti-replay for new network transactions on the old network); also fixing the O(n^2) bug (objectives A and D)</div><div class=""><br class=""></div><div class="">3. This is to prepare for the next hardfork from the new network (objective A)</div><div class=""><br class=""></div><div class="">6, 7, 8. These minimise the change to the existing network (objective C)</div><div class=""><br class=""></div><div class="">9, 10. These are not strictly needed until a hardfork is really anticipated. Without a significant portion of the network and miners implement this policy, however, no one should create such transactions. (objective A)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Limitations:</div><div class=""><br class=""></div><div class="">* It is not possible to protect transactions made before the proposal. To avoid a replay of such transactions, users should first spend at least a relevant UTXO on the new network so the replay transaction would be invalidated.</div><div class=""><br class=""></div><div class="">* It is up to the designer of a hardfork to decide whether this proposal is respected. As the DAO hardfork has shown how harmful replay attack could be, all hardfork proposals (except trivial and totally uncontroversial ones) should take this into account</div><div class=""><br class=""></div><div class="">* The size of network characteristic byte is limited to 8 bits. However, if we are sure that some of the networks are completely abandoned, the bits might be reused.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Reference implementation:</div><div class=""><br class=""></div><div class="">A demo is available in my forcenet2 branch:&nbsp;<a href="https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a" class="">https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a</a></div><div class=""><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html" class="">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html</a></div></body></html>