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
|
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 38030BC0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 07:22:24 +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 94C5C140
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 07:22:23 +0000 (UTC)
Received: from [192.168.1.111] (137.189.135.19 [137.189.135.19]) by
mx.zohomail.com with SMTPS id 1485328921028196.11692641878324;
Tue, 24 Jan 2017 23:22:01 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <45F53199-C8AC-4DD3-B746-D56F9F01946B@xbt.hk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_FDE79A39-A0C4-46E7-A6F0-630708C549A5"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 25 Jan 2017 15:21:57 +0800
In-Reply-To: <CAAt2M1_cQTfaDyQkaixeFB5Ubi35fSOs9Ks74WZEehtFk__B3w@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
<CAAt2M1_=8jDWuyO5_n8aXXDVYypvGQ2uL6zkJNn1ZnQOaXM6nQ@mail.gmail.com>
<311FE02A-F3B5-4F88-B6C8-F0E78CC46903@xbt.hk>
<CAAt2M1_cQTfaDyQkaixeFB5Ubi35fSOs9Ks74WZEehtFk__B3w@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:22:24 -0000
--Apple-Mail=_FDE79A39-A0C4-46E7-A6F0-630708C549A5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Assuming Alice is paying Bob with an old style time-locked tx. Under =
your proposal, after the hardfork, Bob is still able to confirm the =
time-locked tx on both networks. To fulfil your new rules he just needs =
to send the outputs to himself again (with different tx format). But as =
Bob gets all the money on both forks, it is already a successful replay
> On 25 Jan 2017, at 15:15, Natanael <natanael.l@gmail.com> wrote:
>=20
>=20
> Den 25 jan. 2017 08:06 skrev "Johnson Lau" <jl2012@xbt.hk =
<mailto:jl2012@xbt.hk>>:
> 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.
>=20
> Read it again.=20
>=20
> The validation algorithm would be extended so that the transaction =
can't be replayed, because replaying it in the other network REQUIRES a =
child transaction in the same block that is valid, a child transaction =
the is unique to the network. By doing this policy change simultaneously =
in both networks, old pre-signed transactions *can not be replayed by =
anybody but the owner* of the coins (as he must spend them immediately =
in the child transaction).=20
>=20
> It means that as soon as spent, the UTXO sets immediately and =
irrevocably diverges across the two networks. Which is the entire point, =
isn't it?=20
--Apple-Mail=_FDE79A39-A0C4-46E7-A6F0-630708C549A5
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"">Assuming Alice is paying Bob with an old =
style time-locked tx. Under your proposal, after the hardfork, Bob is =
still able to confirm the time-locked tx on both networks. To fulfil =
your new rules he just needs to send the outputs to himself again (with =
different tx format). But as Bob gets all the money on both forks, it is =
already a successful replay</div><div class=3D""><br class=3D""></div><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
25 Jan 2017, at 15:15, 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 class=3D"gmail_extra" dir=3D"auto"><br class=3D""><div =
class=3D"gmail_quote">Den 25 jan. 2017 08:06 skrev "Johnson Lau" <<a =
href=3D"mailto:jl2012@xbt.hk" class=3D"">jl2012@xbt.hk</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"">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></div></blockquote></div></div><div dir=3D"auto" =
class=3D""><br class=3D""></div><div dir=3D"auto" class=3D"">Read it =
again. </div><div dir=3D"auto" class=3D""><br class=3D""></div><div =
dir=3D"auto" class=3D"">The validation algorithm would be extended so =
that the transaction can't be replayed, because replaying it in the =
other network REQUIRES a child transaction in the same block that is =
valid, a child transaction the is unique to the network. By doing this =
policy change simultaneously in both networks, old pre-signed =
transactions *can not be replayed by anybody but the owner* of the coins =
(as he must spend them immediately in the child =
transaction). </div><div dir=3D"auto" class=3D""><br =
class=3D""></div><div dir=3D"auto" class=3D"">It means that as soon as =
spent, the UTXO sets immediately and irrevocably diverges across the two =
networks. Which is the entire point, isn't it? </div><div =
class=3D"gmail_extra" dir=3D"auto"></div></div>
</div></blockquote></div><br class=3D""></body></html>=
--Apple-Mail=_FDE79A39-A0C4-46E7-A6F0-630708C549A5--
|
