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
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
|
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 266956C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Nov 2017 05:02:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com
[209.85.215.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 08A52FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Nov 2017 05:02:50 +0000 (UTC)
Received: by mail-lf0-f48.google.com with SMTP id e143so24776972lfg.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Nov 2017 21:02:50 -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=SrPJjw1Pa6iOqE07RCuExg8LOefkccLA0i79uFq2DDQ=;
b=e2c9UbJhKpV0QjYTa0j+NkbQPL8zHCD/xAUtK8z5KyuoIUBDPgJeR4gIv22GlX+G36
9dA2wgv1Ymm+WaNCtRPZu5zFYBv/+CkaCRMbnx5udjWF0HpPqtDQmxowpbxCU0L9EVzz
3SM4uMpTUZb3KiCwUYo/VIijl7jkfRHhsnF/lxkrFiuzaitwp1KmDofFWWhrnqoq+O7V
FcjPfkSQs+khRZzkUKD+AIIaJsjtrR51W5egXCqircp7Gd76TxV0MOW3LqV51NLAPdgI
dNTib5Th3OCBy/Hn/5sNOj8UWxfdykgVN3N6v9ovIGb0oTbYZJXqcP4ys6cj03yVh3xe
YTbA==
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=SrPJjw1Pa6iOqE07RCuExg8LOefkccLA0i79uFq2DDQ=;
b=kcWavNROkUNaG3KouaDvDvdoG5u5m+9tPV4g4DYgdD8qXLu6/SWWsreAX1MdvFBal0
PIYqus541fgHKlVLSxiIMiO1JFPeLl4YqZtYtDjSIMlOwZJqY9r1qKTM5H3qwJTa3CYt
KIAUBwU3+4Dea7alRoJoV9D8MxxYS1I+H1pr3Awtpe85Kp8KK3MdfLv4Bb/TEYETSfnl
rlmdVgfVOCaJ7rAWNKzoF5WUcE+MM2dZK3XrdM8C4qcvs5Q5cziwP1/akL52v7rdtUN2
Ro+45w5MT+VUpzp28qoBa3sD87zKYrzjaX8r1ZgXHapvgh7E+YOSE+fj/HvSMOd+514R
FemA==
X-Gm-Message-State: AJaThX4USAK5BwDszp7Fy+e+gkJ+lcKeU2Uj7sXX7lCjdAt7Xy9dLHAb
S/tZulIb8qCrmIp60HZmvw1cVvkxdBEdKc1iZw8=
X-Google-Smtp-Source: AGs4zMaVNL1goiKp+DIgPfxM9v1PVGa94aUcVTIo4pPWzyvijIR8EM2S98oDtPwiocA0eTF+xA3QDWnfkvT6p3Y7N2A=
X-Received: by 10.46.29.207 with SMTP id w76mr63388lje.171.1510722169295; Tue,
14 Nov 2017 21:02:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.215.19 with HTTP; Tue, 14 Nov 2017 21:02:48 -0800 (PST)
In-Reply-To: <71A64D11-DE57-4AA2-A635-F2AA4DC04909@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>
<CAAUaCygjVDuqmVPS-1thnEbKgKYM9LW-7CsuAAnn7vqntMnWxA@mail.gmail.com>
<CA+Cf5AZT6KtRXmt3X6UiF0tP_hCtbUiUsS3XMXDdoaa0T1tepQ@mail.gmail.com>
<71A64D11-DE57-4AA2-A635-F2AA4DC04909@blockchain.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Wed, 15 Nov 2017 00:02:48 -0500
Message-ID: <CAAUaCyjpH0hAxS7pUzZihft3KDtgB3nkZdT_6JUhmE9hJ7T4sA@mail.gmail.com>
To: Mats Jerratsch <mats@blockchain.com>
Content-Type: multipart/alternative; boundary="94eb2c1a64324156d4055dfe6af8"
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: Wed, 15 Nov 2017 11:16:06 +0000
Cc: Bitcoin Protocol Discussion <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: Wed, 15 Nov 2017 05:02:52 -0000
--94eb2c1a64324156d4055dfe6af8
Content-Type: text/plain; charset="UTF-8"
>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>
OK, but then it seems to me you have a dilemma for, eg, your LN commitment
tx. You either give it the specific nForkId of the fork it's created on -
making it invalid on *all* other forks (eg, any future "non-contentious
upgrade" HF that replaces that fork). Or you give it nForkId 0 - which has
the "BCH tx valid on Segwit2x (& vice versa)" flaw.
It may make sense to revise your proposal to incorporate Luke's
OP_CHECKBLOCKATHEIGHT
<https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki>, and make
the fork ID a (block height, hash) pair rather than just a number. But I
still think the idea of fork-specific addresses is a keeper!
On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch <mats@blockchain.com> wrote:
>
> But I like the 'old' idea of putting the hash of a block that MUST be on
> the chain that this txn can eventually be added to. If the hash is not a
> valid block on the chain, the txn can't be added.
>
> It means you can choose exactly which forks you want to allow your txn on,
> pre-fork for both, post-fork for only one, and gets round the issue of who
> gets to decide the nForkid value.. since you don't need one. Also, all the
> old outputs work fine, and LN not an issue.
>
> I'm missing why this scheme would be better ?
>
>
> I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the
> sense that they are very difficult to circumvent. However, a fork could
> also follow the original chain in SPV mode and allow transactions protected
> with these mechanism. Since it's fundamentally impossible to disallow
> transactions in future projects, the goal shouldn't be to make this overly
> complicated.
>
> Furthermore, this schema is not just adding replay protection. It makes
> transacting safer overall (due to a dedicated address format per fork) and
> allows light clients to differentiate between multiple forks. In the past
> three months, at least $600k has been lost by users sending BCH to a BTC
> address [1].
>
> 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.
>>
>
> Whether the transaction is replay protected or not is specified by setting
> a bit in the `SigHashId`. If this bit is set, then the signature *preimage*
> MUST have `nForkId` appended. `nForkId` is not part of the final
> transaction, someone who wants to verify the transaction must know which
> `nForkId` it was created with.
>
> If the bit isn't set, it means `nForkId=0`, which allows other forks to
> validate the signature.
>
> 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...
>>
>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>
> [1]
> https://twitter.com/khannib/status/930223617744437253
>
--94eb2c1a64324156d4055dfe6af8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><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>Sorry, I w=
as careless with the use of `>=3D` there. You are correct, forks form a =
tree. For this proposal, every leaf must be assigned a unique `nForkId`. Th=
e relationship between `nForkId` is irrelevant (e.g. which number is bigger=
), as long as they are unique. Transactions are only valid IFF `nForkId` ma=
tches exactly the `nForkId` of the software validating it. As described abo=
ve, the transaction doesn't even contain `nForkId`, and the node surely=
is not starting to guess which one it could be.=C2=A0</div></div></blockqu=
ote></div></div><div><br></div><div>OK, but then it seems to me you have a =
dilemma for, eg, your LN commitment tx.=C2=A0 You either give it the specif=
ic nForkId of the fork it's created on - making it invalid on <i>all</i=
> other forks (eg, any future "non-contentious upgrade" HF that r=
eplaces that fork).=C2=A0 Or you give it nForkId 0 - which has the "BC=
H tx valid on Segwit2x (& vice versa)" flaw.</div><div><br></div><=
div>It may make sense to revise your proposal to incorporate Luke's <a =
href=3D"https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki">OP_=
CHECKBLOCKATHEIGHT</a>, and make the fork ID a (block height, hash) pair ra=
ther than just a number.=C2=A0 But I still think the idea of fork-specific =
addresses is a keeper!</div><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch <span dir=
=3D"ltr"><<a href=3D"mailto:mats@blockchain.com" target=3D"_blank">mats@=
blockchain.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div style=3D"word-wrap:break-word"><div><span class=3D"gmai=
l-"><br><blockquote type=3D"cite"><div><div dir=3D"auto"><div dir=3D"auto">=
But I like the 'old' idea of putting the hash of a block that MUST =
be on the chain that this txn can eventually be added to. If the hash is no=
t a valid block on the chain, the txn can't be added.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It means you can choose exactly which=
forks you want to allow your txn on, pre-fork for both, post-fork for only=
one, and gets round the issue of who gets to decide the nForkid value.. si=
nce you don't need one. Also, all the old outputs work fine, and LN not=
an issue.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I'm missi=
ng why this scheme would be better ?<br></div></div></div></blockquote><div=
><br></div></span><div>I do agree that solutions like `SIGHASH_BLOCKCOMMIT`=
are superior in the sense that they are very difficult to circumvent. Howe=
ver, a fork could also follow the original chain in SPV mode and allow tran=
sactions protected with these mechanism. Since it's fundamentally impos=
sible to disallow transactions in future projects, the goal shouldn't b=
e to make this overly complicated.=C2=A0</div><div><br></div><div>Furthermo=
re, this schema is not just adding replay protection. It makes transacting =
safer overall (due to a dedicated address format per fork) and allows light=
clients to differentiate between multiple forks. In the past three months,=
at least $600k has been lost by users sending BCH to a BTC address [1].</d=
iv><span class=3D"gmail-"><div><br></div><blockquote type=3D"cite"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr">Thanks for the clarification.=C2=A0 H=
ow would a tx specify a constraint like "nForkId>=3D1"?=C2=A0 =
I was thinking of it just as a number set on the tx.</div></blockquote></di=
v></div></blockquote><div><br></div></span><div>Whether the transaction is =
replay protected or not is specified by setting a bit in the `SigHashId`. I=
f this bit is set, then the signature *preimage* MUST have `nForkId` append=
ed. `nForkId` is not part of the final transaction, someone who wants to ve=
rify the transaction must know which `nForkId` it was created with.=C2=A0</=
div><div><br></div><div>If the bit isn't set, it means `nForkId=3D0`, w=
hich allows other forks to validate the signature.</div><span class=3D"gmai=
l-"><div><br></div><blockquote type=3D"cite"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div>Also note that since forks form a partial order, but I=
Ds (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 forked (from BTC!=
) with nForkId 3.=C2=A0 The BCH funding tx would be valid on Segwit2x.=C2=
=A0 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=
9;s first block or something, someone has written about this...<br></div></=
div></blockquote></div></div></blockquote><div><br></div></span><div>Sorry,=
I was careless with the use of `>=3D` there. You are correct, forks for=
m a tree. For this proposal, every leaf must be assigned a unique `nForkId`=
. The relationship between `nForkId` is irrelevant (e.g. which number is bi=
gger), as long as they are unique. Transactions are only valid IFF `nForkId=
` matches exactly the `nForkId` of the software validating it. As described=
above, the transaction doesn't even contain `nForkId`, and the node su=
rely is not starting to guess which one it could be.=C2=A0</div></div><br><=
div>[1]</div><div><a href=3D"https://twitter.com/khannib/status/93022361774=
4437253" target=3D"_blank">https://twitter.com/khannib/<wbr>status/93022361=
7744437253</a></div></div></blockquote></div><br></div></div>
--94eb2c1a64324156d4055dfe6af8--
|