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
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
|
Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 259EEAE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Nov 2017 15:31:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com
[209.85.215.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E359AE5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Nov 2017 15:31:57 +0000 (UTC)
Received: by mail-lf0-f42.google.com with SMTP id r135so18814813lfe.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Nov 2017 07:31:57 -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=SM7v/7jxtKXxVA4AYWJ7iRLOvwrrQSfDHBvlfll5JMg=;
b=oCVfODWdWAhC7pUja6/e4QZ3ULcG2jLapFyMf+Vhdv798C4Q8En6jSo+jmi0Pdxzuv
m/lYPc78CH+h5wcI8Rhf+nqI8t0VJx4f9DaOGHGEukGzqFeAsEDkk7zOEUrS3rI9mRor
Fywd1zmtauF7biyf5422Yfuck80oRT8kBoGuQIYn7jTCyMk1PFOxBGfUeVx25VkWhnTT
JmwstPMEx6v2ktHT1XSdT9nxuqyt26geD7VNjrXH1UrPzSYMkrFRSPTTsJ3X3l1+BcEy
yImJVGRm6C2nmU5rCiOdp2QouMUQiO039JPAljSgxOkOd+6efGRK6DSI299rA3XzxwXG
2rAA==
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=SM7v/7jxtKXxVA4AYWJ7iRLOvwrrQSfDHBvlfll5JMg=;
b=kPpiIT7E5s8wlawBty1fu8NZQ34gF9d0L0G38rt1zZnuAtjFIvZHqb+v2HpBugh6to
u7wIAH/YTm6Kf8qmqR5pDEYc8HbmmEGnPOlh4NgZIpfhm6R3gcUdX4azxbQ+QQg0bnRY
UQMirFrXCiG81ywTQwToMumG8J5ZFfkg+AM8D0ZnCMKowG6gYhqmg/xR6hlz927HoFx1
C6p9Abg74AwMrZTdqLezPHUb7LG+UcBTnAI2Z8yJzicC7tClZG6d2WbfxjMXWIqSaAB4
ov3FmstSccnGwQL1N9eXfPOTnxdptaFR13JZf+Pv0p5ez7yBz//a7HRZOMySs/AOw4wf
MmRQ==
X-Gm-Message-State: AJaThX51017YllUOsk9qkxwJmWTx2wDG4qMX57pBKyWXrslTH6rb/y+F
Fy3jqSuOTDsPF6KCtNUzHoesi8ShQ8oGqcv2En4Udjyu
X-Google-Smtp-Source: AGs4zMaPFiex1vNLf4jBvyzJzR3PDHunBbe92+BS2oWQhCXJmo8vxZu+4gGap0php81cjOtkGwQ2hwTIpB9RWBPDI/M=
X-Received: by 10.25.78.91 with SMTP id c88mr2349414lfb.4.1510587116287; Mon,
13 Nov 2017 07:31:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.168.7 with HTTP; Mon, 13 Nov 2017 07:31:55 -0800 (PST)
In-Reply-To: <24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com>
References: <7601C2CD-8544-4501-80CE-CAEB402A72D2@blockchain.com>
<CAAUaCyii2U5VBLS+Va+F3h4Hka0OWDnFFmjtsvyaaD4TKVzV3Q@mail.gmail.com>
<CAAUaCyiZ0bmWZLZc-yDvVHupzbdRR=Kdq4P8VkWqpU1L3G-u3A@mail.gmail.com>
<C9A47922-5777-44AC-871A-6C27A22054AC@blockchain.com>
<CAAUaCyjVxJbPrbBUdb9irK5CNnuqUSnzSjywpozhLqONcb_m_w@mail.gmail.com>
<45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl>
<CAAUaCygeOxAK=EpzfWndx6uVvVO9B+=YTs1m-jHa3BFp82jA4w@mail.gmail.com>
<95ECB451-56AE-45E5-AAE6-10058C4B7FD7@sprovoost.nl>
<CAAUaCyg_PGT0F=RHfX89T54j-vuyz5wcbXaYoikJv95WKgsNPg@mail.gmail.com>
<55467A01-A8B2-4E73-8331-38C0A7CD90EF@sprovoost.nl>
<CAAUaCyhncyCt_ao9i0=33LswDOkCf6o-+36zrGxKWD+WranmZw@mail.gmail.com>
<46E317DF-C97C-4797-B989-594298BC6030@sprovoost.nl>
<CAAUaCyibOEHqw1J5O8yEp8v=j8t9sovn2vn=S8bZPZCzCY-gRw@mail.gmail.com>
<3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com>
<CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com>
<24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Mon, 13 Nov 2017 10:31:55 -0500
Message-ID: <CAAUaCygjVDuqmVPS-1thnEbKgKYM9LW-7CsuAAnn7vqntMnWxA@mail.gmail.com>
To: Mats Jerratsch <mats@blockchain.com>
Content-Type: multipart/alternative; boundary="94eb2c1cdbb677fb60055ddef821"
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 13 Nov 2017 15:34:38 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard
Forks
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: Mon, 13 Nov 2017 15:31:59 -0000
--94eb2c1cdbb677fb60055ddef821
Content-Type: text/plain; charset="UTF-8"
>
> This is actually incorrect. There are two transactions involved in LN. The
> funding transaction, which opens a payment channel, and a commitment
> transaction, which closes the channel when broadcasted to the network (the
> cooperative closing transaction can be considered a commitment transaction
> in a loose sense).
>
> Now you want to protect the funding transaction, as otherwise you would be
> subject to a replay-attack on all *past* forks. So you will set
> `nForkId>=1` for the funding transaction, making this payment channel
> non-existent on any *past* forks. However, if during the lifetime of the
> payment channel another fork happens, the payment channel exists for both
> tokens. So for the commitment transaction, you will have `nForkId=0`,
> making it valid on both of these chains. While this `nForkId` is valid on
> all chains, the parent transaction it tries to spend (the funding
> transaction) does only exist on two chains, the original one you created
> the channel for and the one that forked away.
>
Thanks for the clarification. How would a tx specify a constraint like
"nForkId>=1"? I was thinking of it just as a number set on the tx.
Also note that since forks form a partial order, but IDs (numbers) form a
total order, ">=" will miss some cases. Eg, suppose BCH had forked with
nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and
then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would
be valid on Segwit2x. This is more of a fundamental problem than a bug -
to avoid it you'd have to get into stuff like making each fork reference
its parent-fork's first block or something, someone has written about
this...
On Mon, Nov 13, 2017 at 5:03 AM, Mats Jerratsch <mats@blockchain.com> wrote:
>
> OK, so nForkId 0 is exactly the "valid on all chains" specifier I was
> asking about, cool. And your LN example (and nLockTime txs in general)
> illustrate why it's preferable to implement a generic replay protection
> scheme like yours *in advance*, rather than before each fork: all ad hoc
> RP schemes I know of break old txs on one of the chains, even when that's
> not desirable - ie, they offer no wildcard like nForkId 0.
>
>
> Exactly!
>
> One comment on your LN example: users would have to take note that nForkId
> 0 txs would be valid not only on future forks, but on *past* forks too.
> Eg, if BCH had been deployed with nForkId 2, then a user setting up BTC LN
> txs now with nForkId 0 would have to be aware that those txs would be valid
> for BCH too. Of course the user could avoid this by funding from a
> BTC-only address, but it is a potential minor pitfall of nForkId 0. (Which
> I don't see any clean way around.)
>
>
> This is actually incorrect. There are two transactions involved in LN. The
> funding transaction, which opens a payment channel, and a commitment
> transaction, which closes the channel when broadcasted to the network (the
> cooperative closing transaction can be considered a commitment transaction
> in a loose sense).
>
> Now you want to protect the funding transaction, as otherwise you would be
> subject to a replay-attack on all *past* forks. So you will set
> `nForkId>=1` for the funding transaction, making this payment channel
> non-existent on any *past* forks. However, if during the lifetime of the
> payment channel another fork happens, the payment channel exists for both
> tokens. So for the commitment transaction, you will have `nForkId=0`,
> making it valid on both of these chains. While this `nForkId` is valid on
> all chains, the parent transaction it tries to spend (the funding
> transaction) does only exist on two chains, the original one you created
> the channel for and the one that forked away.
>
--94eb2c1cdbb677fb60055ddef821
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v style=3D"word-wrap:break-word"><div>This is actually incorrect. There are=
two transactions involved in LN. The funding transaction, which opens a pa=
yment channel, and a commitment transaction, which closes the channel when =
broadcasted to the network (the cooperative closing transaction can be cons=
idered a commitment transaction in a loose sense).=C2=A0</div><div><br></di=
v><div>Now you want to protect the funding transaction, as otherwise you wo=
uld be subject to a replay-attack on all *past* forks. So you will set `nFo=
rkId>=3D1` for the funding transaction, making this payment channel non-=
existent on any *past* forks. However, if during the lifetime of the paymen=
t channel another fork happens, the payment channel exists for both tokens.=
So for the commitment transaction, you will have `nForkId=3D0`, making it =
valid on both of these chains. While this `nForkId` is valid on all chains,=
the parent transaction it tries to spend (the funding transaction) does on=
ly exist on two chains, the original one you created the channel for and th=
e one that forked away.=C2=A0</div></div></blockquote></div><div><br></div>=
Thanks for the clarification.=C2=A0 How would a tx specify a constraint lik=
e "nForkId>=3D1"?=C2=A0 I was thinking of it just as a number =
set on the tx.<div><br></div><div>Also note that since forks form a partial=
order, but IDs (numbers) form a total order, ">=3D" will miss=
some cases.=C2=A0 Eg, suppose BCH had forked with nForkId 2, and then you =
set up a LN funding tx on BCH with nForkId>=3D2, and then Segwit2x forke=
d (from BTC!) with nForkId 3.=C2=A0 The BCH funding tx would be valid on Se=
gwit2x.=C2=A0 This is more of a fundamental problem than a bug - to avoid i=
t you'd have to get into stuff like making each fork reference its pare=
nt-fork's first block or something, someone has written about this...<b=
r><div><div><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Mon, Nov 13, 2017 at 5:03 AM, Mats Jerratsch <span dir=3D"ltr"><<a hre=
f=3D"mailto:mats@blockchain.com" target=3D"_blank">mats@blockchain.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
style=3D"word-wrap:break-word"><div><span class=3D"gmail-"><br><blockquote=
type=3D"cite"><div><div dir=3D"ltr">OK, so nForkId 0 is exactly the "=
valid on all chains" specifier I was asking about, cool.=C2=A0 And you=
r LN example (and nLockTime txs in general) illustrate why it's prefera=
ble to implement a generic replay protection scheme like yours <i>in advanc=
e</i>, rather than before each fork: all ad hoc RP schemes I know of break =
old txs on one of the chains, even when that's not desirable - ie, they=
offer no wildcard like nForkId 0.</div></div></blockquote><div><br></div><=
/span><div>Exactly!</div><span class=3D"gmail-"><div><br></div><blockquote =
type=3D"cite"><div><div dir=3D"ltr"><div>One comment on your LN example: us=
ers would have to take note that nForkId 0 txs would be valid not only on f=
uture forks, but on <i>past</i> forks too.=C2=A0 Eg, if BCH had been deploy=
ed with nForkId 2, then a user setting up BTC LN txs now with nForkId 0 wou=
ld have to be aware that those txs would be valid for BCH too.=C2=A0 Of cou=
rse the user could avoid this by funding from a BTC-only address, but it is=
a potential minor pitfall of nForkId 0.=C2=A0 (Which I don't see any c=
lean way around.)</div></div>
</div></blockquote></span></div><br><div>This is actually incorrect. There =
are two transactions involved in LN. The funding transaction, which opens a=
payment channel, and a commitment transaction, which closes the channel wh=
en broadcasted to the network (the cooperative closing transaction can be c=
onsidered a commitment transaction in a loose sense).=C2=A0</div><div><br><=
/div><div>Now you want to protect the funding transaction, as otherwise you=
would be subject to a replay-attack on all *past* forks. So you will set `=
nForkId>=3D1` for the funding transaction, making this payment channel n=
on-existent on any *past* forks. However, if during the lifetime of the pay=
ment channel another fork happens, the payment channel exists for both toke=
ns. So for the commitment transaction, you will have `nForkId=3D0`, making =
it valid on both of these chains. While this `nForkId` is valid on all chai=
ns, the parent transaction it tries to spend (the funding transaction) does=
only exist on two chains, the original one you created the channel for and=
the one that forked away.=C2=A0</div></div></blockquote></div><br></div></=
div></div></div></div>
--94eb2c1cdbb677fb60055ddef821--
|
