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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 13264BC0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 07:06:09 +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 5E36DE3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 07:06:07 +0000 (UTC)
Received: from [192.168.1.111] (137.189.135.19 [137.189.135.19]) by
mx.zohomail.com with SMTPS id 1485327963372401.4201404595159;
Tue, 24 Jan 2017 23:06:03 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <311FE02A-F3B5-4F88-B6C8-F0E78CC46903@xbt.hk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_9112B49E-3140-458F-A6FA-F05F98DF32A4"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 25 Jan 2017 15:05:59 +0800
In-Reply-To: <CAAt2M1_=8jDWuyO5_n8aXXDVYypvGQ2uL6zkJNn1ZnQOaXM6nQ@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
<CAAt2M1_=8jDWuyO5_n8aXXDVYypvGQ2uL6zkJNn1ZnQOaXM6nQ@mail.gmail.com>
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
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.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 07:06:09 -0000
--Apple-Mail=_9112B49E-3140-458F-A6FA-F05F98DF32A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
What you describe is not a fix of replay attack. By confirming the same =
tx in both network, the tx has been already replayed. Their child txs do =
not matter.
> On 25 Jan 2017, at 09:22, Natanael <natanael.l@gmail.com> wrote:
>=20
>=20
>=20
> Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>>:
>=20
>=20
> 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.
>=20
> This can be fixed.=20
>=20
> 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.=20
>=20
> (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.)
>=20
> Meanwhile, the old network SHOULD soft-fork in an identical rule with =
a follow-up transaction format incompatible with the fork.=20
>=20
> 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).=20=
>=20
> 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.=20
>=20
>=20
--Apple-Mail=_9112B49E-3140-458F-A6FA-F05F98DF32A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">What you describe is not a fix of replay =
attack. By confirming the same tx in both network, the tx has been =
already replayed. Their child txs do not matter.</div><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
25 Jan 2017, at 09:22, Natanael <<a =
href=3D"mailto:natanael.l@gmail.com" =
class=3D"">natanael.l@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"auto" =
class=3D""><div data-smartmail=3D"gmail_signature" dir=3D"auto" =
class=3D""><br class=3D""></div><div class=3D"gmail_extra" =
dir=3D"auto"><br class=3D""><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" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>>:<br =
type=3D"attribution" class=3D""><blockquote class=3D"quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><br class=3D""></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""></div></div></blockquote></div></div><div dir=3D"auto" =
class=3D""><br class=3D""></div><div dir=3D"auto" class=3D"">This can be =
fixed. </div><div dir=3D"auto" class=3D""><br class=3D""></div><div =
dir=3D"auto" class=3D"">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. </div><div dir=3D"auto" class=3D""><br =
class=3D""></div><div dir=3D"auto" class=3D"">(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.)</div><div =
dir=3D"auto" class=3D""><br class=3D""></div><div dir=3D"auto" =
class=3D"">Meanwhile, the old network SHOULD soft-fork in an identical =
rule with a follow-up transaction format incompatible with the =
fork. </div><div dir=3D"auto" class=3D""><br class=3D""></div><div =
dir=3D"auto" class=3D"">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). </div><div dir=3D"auto" class=3D""><br =
class=3D""></div><div dir=3D"auto" class=3D"">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. </div><div =
dir=3D"auto" class=3D""><br class=3D""></div><div dir=3D"auto" =
class=3D""><br class=3D""></div></div>
</div></blockquote></div><br class=3D""></body></html>=
--Apple-Mail=_9112B49E-3140-458F-A6FA-F05F98DF32A4--
|
