This is a pre-BIP. Just need some formatting to make it a formal BIP
Motivation:
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.
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.
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:
A. For users on both existing and new fork, anti-replay is an option, not
mandatory.
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.
C. It doesn’t require any consensus changes in the existing network to avoid
unnecessary debate.
D. As a beneficial side effect, the O(n^2) signature checking bug could be
fixed for non-segregated witness inputs, optionally.
Definitions:
“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.
“Masked version” is the transaction nVersion with the network characteristic
byte masked.
“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)
“Existing network characteristic bit” is the lowest bit of network
characteristic byte
“New network characteristic bit” is the second lowest bit of network
characteristic byte
Rules in new network:
1. If the network characteristic byte is non-zero, and the new network
characteristic bit is not set, this transaction is invalid in the new network.
(softfork)
2. If the network characteristic byte is zero, go to 4
3. If the network characteristic byte is non-zero, and the new network
characteristic bit is set, go to 4, regardless of the status of the other bits.
4. If the masked version is 2 or below, the new network must verify the
transaction with the existing script rules. (no change)
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.
Rules in the existing network:
6. No consensus rule changes is made in the existing network.
7. 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 (no change)
8. If the network characteristic byte is zero, no change
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)
10. Wallet may provide an option for setting the existing network
characteristic bit.
Rationales (by rule number):
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)
2+4. This makes sure time-locked transactions made before this proposals are
valid in the new network (objective B)
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)
3. This is to prepare for the next hardfork from the new network (objective A)
6, 7, 8. These minimise the change to the existing network (objective C)
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)
Limitations:
* 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.
* 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
* 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.
Reference implementation:
A demo is available in my forcenet2 branch:
https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a
<https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
