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
|
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 AB029BD0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 07:29:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com
[209.85.161.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2BC3E8C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Jan 2017 07:29:15 +0000 (UTC)
Received: by mail-yw0-f175.google.com with SMTP id w75so6897788ywg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Jan 2017 23:29:15 -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
:cc; bh=NQBnzF1VS30ZjbJrc1UG6XvAxIMjVaEkTmUq6Mz9E1k=;
b=gk0e3LqZw8dHkXyh+zTtHh3a+KvobutgUlYCfMHsYsV9Q+RdXqJwBp5eVHvv+LKIi/
5VnT+hCxApLhkVfapffP84qA4s5nn7bEAFmfQawherGnNmrRCOOAw7gM7YtmOcmmwhPY
wDhM+n+wNcorHJEbl7Bz7CwsSJ/4WORsT0X5fXMvPyVG9oAj8jXkgJqkiAFkNZ/Xp5Uh
KdTyDGOIr4j0k8ZxOZXo5eus7pHz22RJF/RGLcUm4lu6X5srURTwLAiNvx+Dh2+hT2AH
NRaXdhhUY2Nc0q0wbDL12zq/aVHF6oE1wADWo2BGms3gH3OHQcf+4rLqJatoZ/2zW9ca
Bulg==
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:cc;
bh=NQBnzF1VS30ZjbJrc1UG6XvAxIMjVaEkTmUq6Mz9E1k=;
b=Sjo4+OPsGLAIFHwZrvSBk+iqAhatLyUkqQ9DALzqQkTPKcm3GgK5KtIQnFBVBNyGEM
GxYBhunYuWa8hh7+JssQz2NPg79267JQMjVOZlcQ3oYY1DDAKNFD/Iz1rRaesjFF7n4j
CG0Vyg+qfNF7eUedBwOoqnirmgfYjYhCiNqmOJdvX2n139M5Nz04hGl+emuVlZWKdDQM
VQYw1gHTnfWim19cLmr8aX2JPYv4YfTzjl+5QGqHHs9No5RClAo+M0me/AngfnBmz8Dm
3wD7rJBLzIczNkG+ASz1hYIqWs9bVUNdM25LZe5T+vc7qHYWvpjNUtKVIZ2tKJsbEuiO
C0og==
X-Gm-Message-State: AIkVDXLV6LyQoqmbLWIl64U2D414gZ2s7L4XXfQSYfLMlIwTYH6WOtSRfA/vKmwsT7wv9Ctjit3mOhjvtd5m6A==
X-Received: by 10.129.162.151 with SMTP id z145mr20385481ywg.337.1485329354400;
Tue, 24 Jan 2017 23:29:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.75.67 with HTTP; Tue, 24 Jan 2017 23:29:13 -0800 (PST)
Received: by 10.37.75.67 with HTTP; Tue, 24 Jan 2017 23:29:13 -0800 (PST)
In-Reply-To: <45F53199-C8AC-4DD3-B746-D56F9F01946B@xbt.hk>
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>
From: Natanael <natanael.l@gmail.com>
Date: Wed, 25 Jan 2017 08:29:13 +0100
Message-ID: <CAAt2M1945e4jpy_eoZBJnyztVXjFVTJAjMc-u45gMf4ich8sEQ@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=94eb2c11555e8b2ef80546e63046
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
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:29:15 -0000
--94eb2c11555e8b2ef80546e63046
Content-Type: text/plain; charset=UTF-8
Den 25 jan. 2017 08:22 skrev "Johnson Lau" <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
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?
--94eb2c11555e8b2ef80546e63046
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"><div class=3D"gmail_quote">De=
n 25 jan. 2017 08:22 skrev "Johnson Lau" <<a href=3D"mailto:jl=
2012@xbt.hk">jl2012@xbt.hk</a>>:<br type=3D"attribution"><blockquote cla=
ss=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div style=3D"word-wrap:break-word"><div>Assuming Alice is paying=
Bob with an old style time-locked tx. Under your proposal, after the hardf=
ork, Bob is still able to confirm the time-locked tx on both networks. To f=
ulfil your new rules he just needs to send the outputs to himself again (wi=
th 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"><br></div><div dir=3D"auto">Why would Alice be sitting on an old-=
style signed transaction with UTXO:s none of which she controls (paying som=
ebody else), with NO ability to substitute the transaction for one where sh=
e DOES control an output, leaving her unable to be the one spending the rep=
lay protecting child transaction?=C2=A0</div><div class=3D"gmail_extra" dir=
=3D"auto"></div></div>
--94eb2c11555e8b2ef80546e63046--
|
