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
|
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 ECF77BAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 07:42:21 +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 447B18C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 07:42:21 +0000 (UTC)
Received: from [192.168.1.111] (137.189.135.19 [137.189.135.19]) by
mx.zohomail.com with SMTPS id 1485330137416490.44324610576336;
Tue, 24 Jan 2017 23:42:17 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <79668AE7-B05D-41F8-A6DF-EADC05143523@xbt.hk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_786BB037-C098-4636-9F54-3DABCC3B60C9"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 25 Jan 2017 15:42:13 +0800
In-Reply-To: <CAAt2M1945e4jpy_eoZBJnyztVXjFVTJAjMc-u45gMf4ich8sEQ@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>
<45F53199-C8AC-4DD3-B746-D56F9F01946B@xbt.hk>
<CAAt2M1945e4jpy_eoZBJnyztVXjFVTJAjMc-u45gMf4ich8sEQ@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:42:22 -0000
--Apple-Mail=_786BB037-C098-4636-9F54-3DABCC3B60C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On 25 Jan 2017, at 15:29, Natanael <natanael.l@gmail.com> wrote:
>=20
>=20
> Den 25 jan. 2017 08:22 skrev "Johnson Lau" <jl2012@xbt.hk =
<mailto:jl2012@xbt.hk>>:
> 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
>=20
> Why would Alice be sitting on an old-style signed transaction with =
UTXO:s none of which she controls (paying somebody else), with NO =
ability to substitute the transaction for one where she DOES control an =
output, leaving her unable to be the one spending the replay protecting =
child transaction?=20
If Alice still has full control, she is already protected by my =
proposal, which does not require any protecting child transaction.
But in many cases she may not have full control. Make it clearer, =
consider that=E2=80=99s actually a 2-of-2 multisig of Alice and Bob, and =
the time locked tx is sending to Bob. If the time locked tx is =
unprotected in the first place, Bob will get all the money from both =
forks anyway, as there is no reason for him to renegotiate with Alice.=
--Apple-Mail=_786BB037-C098-4636-9F54-3DABCC3B60C9
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""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 25 Jan 2017, at 15:29, 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"><div class=3D"gmail_quote">Den 25 jan. 2017 08:22 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"">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></blockquote></div></div><div dir=3D"auto" =
class=3D""><br class=3D""></div><div dir=3D"auto" class=3D"">Why would =
Alice be sitting on an old-style signed transaction with UTXO:s none of =
which she controls (paying somebody else), with NO ability to substitute =
the transaction for one where she DOES control an output, leaving her =
unable to be the one spending the replay protecting child =
transaction? </div><div class=3D"gmail_extra" =
dir=3D"auto"></div></div>
</div></blockquote></div><br class=3D""><div class=3D""><div class=3D"">If=
Alice still has full control, she is already protected by my proposal, =
which does not require any protecting child transaction.</div></div><div =
class=3D""><br class=3D""></div><div class=3D"">But in many cases she =
may not have full control. Make it clearer, consider that=E2=80=99s =
actually a 2-of-2 multisig of Alice and Bob, and the time locked tx is =
sending to Bob. If the time locked tx is unprotected in the first place, =
Bob will get all the money from both forks anyway, as there is no reason =
for him to renegotiate with Alice.</div></body></html>=
--Apple-Mail=_786BB037-C098-4636-9F54-3DABCC3B60C9--
|
