summaryrefslogtreecommitdiff
path: root/8b/aa53c3b69da9e7bfcafb483a3268a4bf1f9f58
blob: 154f2bc4a5f7e478748613d27d685c193edd18d7 (plain)
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 &lt;<a =
href=3D"mailto:natanael.l@gmail.com" =
class=3D"">natanael.l@gmail.com</a>&gt; 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" &lt;<a href=3D"mailto:jl2012@xbt.hk" =
class=3D"">jl2012@xbt.hk</a>&gt;:<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?&nbsp;</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--