From: Johnson Lau <jl2012@xbt.hk>
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: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
Date: Tue, 24 Jan 2017 22:33:29 +0800
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Anti-transaction replay in a hardfork
Precedence: list


--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://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55=
473c682a>
=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/01347=
2.html =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0134=
72.html>=

--Apple-Mail=_DF6AD19A-8B86-4FE0-9ED4-8CDA1C9D212E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">This is a pre-BIP. Just need some formatting =
to make it a formal BIP</div><div class=3D""><br =
class=3D""></div>Motivation:<div class=3D""><br class=3D""></div><div =
class=3D"">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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">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=3D""><br =
class=3D""></div><div class=3D"">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=3D""><br =
class=3D""></div><div class=3D"">A. For users on both existing and new =
fork, anti-replay is an option, not mandatory.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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=3D""><br class=3D""></div><div class=3D"">C. It doesn=E2=80=99t =
require any consensus changes in the existing network to avoid =
unnecessary debate.</div><div class=3D""><br class=3D""></div><div =
class=3D"">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=3D""><br class=3D""></div><div =
class=3D"">Definitions:</div><div class=3D""><br class=3D""></div><div =
class=3D"">=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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">=E2=80=9CMasked version=E2=80=9D is the transaction nVersion =
with the network characteristic byte masked.</div><div class=3D""><br =
class=3D""></div><div class=3D"">=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)</div><div class=3D""><br =
class=3D""></div><div class=3D"">=E2=80=9CExisting network =
characteristic bit=E2=80=9D is the lowest bit of network characteristic =
byte</div><div class=3D""><br class=3D""></div><div class=3D"">=E2=80=9CNe=
w network characteristic bit=E2=80=9D is the second lowest bit of =
network characteristic byte</div><div class=3D""><br class=3D""></div><div=
 class=3D"">Rules in new network:</div><div class=3D""><br =
class=3D""></div><div class=3D""><div class=3D"">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=3D""><br class=3D""></div><div =
class=3D"">2. If the network characteristic byte is zero, go to =
4</div><div class=3D""><br class=3D""></div><div class=3D"">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=3D""><br class=3D""></div><div class=3D"">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=3D""><br class=3D""></div><div class=3D"">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=3D""><br =
class=3D""></div><div class=3D""><div class=3D"">Rules in the existing =
network:</div><div class=3D""><br class=3D""></div><div class=3D"">6. No =
consensus rule changes is made in the existing network.</div></div><div =
class=3D""><br class=3D""></div><div class=3D"">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=3D""><br class=3D""></div><div =
class=3D"">8. If the network characteristic byte is zero, no =
change</div><div class=3D""><br class=3D""></div><div class=3D"">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=3D""><br class=3D""></div><div class=3D"">10. =
Wallet may provide an option for setting the existing network =
characteristic bit.</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">Rationales (by rule =
number):</div><div class=3D""><br class=3D""></div><div class=3D"">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=3D""><br class=3D""></div><div class=3D"">2+4. This makes sure =
time-locked transactions made before this proposals are valid in the new =
network (objective B)</div><div class=3D""><br class=3D""></div><div =
class=3D"">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=3D""><br class=3D""></div><div =
class=3D"">3. This is to prepare for the next hardfork from the new =
network (objective A)</div><div class=3D""><br class=3D""></div><div =
class=3D"">6, 7, 8. These minimise the change to the existing network =
(objective C)</div><div class=3D""><br class=3D""></div><div class=3D"">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=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">Limitations:</div><div =
class=3D""><br class=3D""></div><div class=3D"">* 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=3D""><br class=3D""></div><div class=3D"">* 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=3D""><br =
class=3D""></div><div class=3D"">* 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=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">Reference implementation:</div><div class=3D""><br =
class=3D""></div><div class=3D"">A demo is available in my forcenet2 =
branch:&nbsp;<a =
href=3D"https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e21068311078=
2d82f55473c682a" =
class=3D"">https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e21068311=
0782d82f55473c682a</a></div><div class=3D""><a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Janua=
ry/013472.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ja=
nuary/013472.html</a></div></body></html>=

--Apple-Mail=_DF6AD19A-8B86-4FE0-9ED4-8CDA1C9D212E--