From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D564B932 for ; Tue, 24 Jan 2017 14:33:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B0CA688 for ; Tue, 24 Jan 2017 14:33:34 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1485268412871399.6761932701122; Tue, 24 Jan 2017 06:33:32 -0800 (PST) From: Johnson Lau Content-Type: multipart/alternative; boundary="Apple-Mail=_DF6AD19A-8B86-4FE0-9ED4-8CDA1C9D212E" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Tue, 24 Jan 2017 22:33:29 +0800 To: bitcoin-dev X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Anti-transaction replay in a hardfork X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 14:33:36 -0000 --Apple-Mail=_DF6AD19A-8B86-4FE0-9ED4-8CDA1C9D212E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 (=E2=80=9CD= AO 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=E2=80=99t 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: =E2=80=9CNetwork characteristic byte=E2=80=9D 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. =E2=80=9CMasked version=E2=80=9D is the transaction nVersion with the = network characteristic byte masked. =E2=80=9CExisting network=E2=80=9D is the Bitcoin network with existing = rules, before a hardfork. =E2=80=9CNew network=E2=80=9D 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) =E2=80=9CExisting network characteristic bit=E2=80=9D is the lowest bit = of network characteristic byte =E2=80=9CNew network characteristic bit=E2=80=9D 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/7c2593946c4f3e210683110782d82f554= 73c682a = = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/01347= 2.html = = --Apple-Mail=_DF6AD19A-8B86-4FE0-9ED4-8CDA1C9D212E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 = (=E2=80=9CDAO 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=E2=80=99t = 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:

=E2=80=9CNetwork characteristic byte=E2=80=9D 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.

=E2=80=9CMasked version=E2=80=9D is the transaction nVersion = with the network characteristic byte masked.

=E2=80=9CExisting network=E2=80=9D is = the Bitcoin network with existing rules, before a hardfork. =E2=80=9CNew = network=E2=80=9D 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)

=E2=80=9CExisting network = characteristic bit=E2=80=9D is the lowest bit of network characteristic = byte

=E2=80=9CNe= w network characteristic bit=E2=80=9D 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/7c2593946c4f3e21068311= 0782d82f55473c682a
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ja= nuary/013472.html
= --Apple-Mail=_DF6AD19A-8B86-4FE0-9ED4-8CDA1C9D212E--