1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 567CBBA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 01:22:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f169.google.com (mail-yw0-f169.google.com
[209.85.161.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3E071D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 01:22:45 +0000 (UTC)
Received: by mail-yw0-f169.google.com with SMTP id l19so176874108ywc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Jan 2017 17:22:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=UhIfjoJ4rQP0BSDfQkDBYUmlc/H9h2azUr1XetpDO6g=;
b=GBhiyE/MLQ0TtajV3LHmFa0r+vUOryoxscpjZDqy3g1spCeuPzFBiva7Vf/txZr003
SLjAmUrsskOkEVBP2FiMgwOAVe9kUfROGyGBIDDC2JxmLRDgIoIf6Bz35ESsKLcPeonk
8EoUgK1uKAHGm/YVes8FEdl/BW71ZUla+OgytU7J/q+t4H5Yi1vRBT7eJMK+KKB92yRz
QbLlFJNxcsIX0niMXpgCoNpCXzlEdK0+B5s1+m6O7/LIM3yGUaB7o6AIDRJot1UB9uKQ
VWqklANZJR8pbKnbRukh6siqAujYragsooq2L2YKHskvSuDCzec6kwVXwdguT/jax7fa
gmRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=UhIfjoJ4rQP0BSDfQkDBYUmlc/H9h2azUr1XetpDO6g=;
b=UJxbIpOiJK/uvlDmAxOH4xFNd0w2pyozvUtJX0vO25YoaJIBeT5HX2O0NEtPeLuXzb
2yODFze8BpZpf5qXCiX6IUTwCwfdD9an/nIGaXnShVQU0Cs/wCdm1H210M2+WRVsgVJW
ikKiGopoxIjYz0aPiL3EdG2Sg+/PaC94hjDh+MJti4yKqXwumLW4IohsfPXjLgeJKU16
7GPf3ICQZlNlZfbRNKqpa8evHdKD6P7D8pBj9WXS33CtcD+KS9HFi+XTnOrW/FnfAsgG
n+5vkXyRmJeW5YiEqEjDnME1dG8+4loije2R9evmbuHNJtxDILWvR1x/Vsj7RXWb3ozm
vEqA==
X-Gm-Message-State: AIkVDXI7YPhUcWPV9qSnIq+iwHFotOigl8X/IzGV0lWT3tDMUqDgpkzW/hj0ijhORsmeGOIEeZHltQv6Cor8Bg==
X-Received: by 10.13.232.83 with SMTP id r80mr33811705ywe.101.1485307364937;
Tue, 24 Jan 2017 17:22:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.75.67 with HTTP; Tue, 24 Jan 2017 17:22:44 -0800 (PST)
Received: by 10.37.75.67 with HTTP; Tue, 24 Jan 2017 17:22:44 -0800 (PST)
In-Reply-To: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
From: Natanael <natanael.l@gmail.com>
Date: Wed, 25 Jan 2017 02:22:44 +0100
Message-ID: <CAAt2M1_=8jDWuyO5_n8aXXDVYypvGQ2uL6zkJNn1ZnQOaXM6nQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=94eb2c084140de94860546e111be
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2017 01:22:46 -0000
--94eb2c084140de94860546e111be
Content-Type: text/plain; charset=UTF-8
Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
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.
This can be fixed.
Make old-format transactions valid *only when paired with a fork-only
follow-up transaction* which is spending at least one (or all) of the
outputs of the old-format transaction.
(Yes, I know this introduces new statefulness into the block validation
logic. Unfortunately it is necessary for maximal fork safety. It can be
disabled at a later time if ever deemed no longer necessary.)
Meanwhile, the old network SHOULD soft-fork in an identical rule with a
follow-up transaction format incompatible with the fork.
This means that old transactions can not be replayed across forks/networks,
because they're not valid when stand-alone. It also means that all wallet
clients either needs to be updated OR paired with software that intercepts
generated transactions, and automatically generates the correct follow-up
transaction for it (old network only).
The rules should be that old-format transactions can't reference new-format
transactions, even if only a softfork change differ between the formats.
This prevents an unnecessary amount of transactions pairs generated by old
wallets. Thus they can spend old outputs, but not spend new ones.
--94eb2c084140de94860546e111be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div data-smartmail=3D"gmail_signature" dir=3D"auto"><br>=
</div><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quote=
">Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" <=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a>>:<br type=3D"attribution"><blockquote class=3D"q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div style=3D"word-wrap:break-word"><div><br></div><div><br></div><div>B=
. For transactions created before this proposal is made, they are not prote=
cted from anti-replay. The new fork has to accept these transactions, as th=
ere is no guarantee that the existing fork would survive nor maintain any v=
alue. 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></=
div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">This can be fixed.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Make old-format transactions valid *only when paired with a fork-onl=
y follow-up transaction* which is spending at least one (or all) of the out=
puts of the old-format transaction.=C2=A0</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">(Yes, I know this introduces new statefulness into the bl=
ock validation logic. Unfortunately it is necessary for maximal fork safety=
. It can be disabled at a later time if ever deemed no longer necessary.)</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Meanwhile, the old networ=
k SHOULD soft-fork in an identical rule with a follow-up transaction format=
incompatible with the fork.=C2=A0</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">This means that old transactions can not be replayed across fork=
s/networks, because they're not valid when stand-alone. It also means t=
hat all wallet clients either needs to be updated OR paired with software t=
hat intercepts generated transactions, and automatically generates the corr=
ect follow-up transaction for it (old network only).=C2=A0</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">The rules should be that old-format tran=
sactions can't reference new-format transactions, even if only a softfo=
rk change differ between the formats. This prevents an unnecessary amount o=
f transactions pairs generated by old wallets. Thus they can spend old outp=
uts, but not spend new ones.=C2=A0</div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><br></div></div>
--94eb2c084140de94860546e111be--
|
