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
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
|
Return-Path: <tom@commerceblock.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8CB79C07FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Apr 2020 22:56:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 7600026754
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Apr 2020 22:56:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id YHz6svvLrPHt
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Apr 2020 22:56:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com
[209.85.208.47])
by silver.osuosl.org (Postfix) with ESMTPS id B1A7520354
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Apr 2020 22:56:30 +0000 (UTC)
Received: by mail-ed1-f47.google.com with SMTP id cw6so6662393edb.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 02 Apr 2020 15:56:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=commerceblock-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=keQMhfOCcXT5UvLSkbZGTS2KLWNDKlPxTWF35U1TUfk=;
b=Din0QbTNvpmernYyhy+P7PvcOkrI78QIxpJ4HlAhDqPB+PwNJD2qA+z+6XQDsxF7MK
f/3JNj5ZmYmHm6vwWpmcxK42H8ow6jjbJJDBC725xOdxRNw3Ua8WRgiccynVMkrka30Z
R3De+ZndyDG5yYCvQvM+r4pRcusAv06TGBjk1S+V4Rli8ZxiMB3qGavV9O0/2U9U90r0
nA3kMaOttoor2qaTml55rKl5tPerbPuaTD3r9w9rBs6SwOU4LvCqtmBhe4LRgduRYIaA
2cIAlzJi/e1+LflzZzhJV+taxREhm0isn0NXBLN2DWMIVHS0MpfP8/N9ttT1voUg26f+
yaFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=keQMhfOCcXT5UvLSkbZGTS2KLWNDKlPxTWF35U1TUfk=;
b=VLKMji18ucAoUrAVjpVwuvGcpxaIyRb1P4Axmjddfws4o7OH8/rhnPn1tNXoeqBgM2
2iQnLE2v9Gb/nq9XjZVrGvCt4KqZ8zga7SN8sOcmOdrC4RUnMA/L2w/h23p3eeeYyjNZ
G24X6pe4/0puTsW2lXMztF9X6U7dhCKcYUGa872nSDdERc95nLTj+VOmekenjzn/DTpG
CXI9S1qOH7yyeHiC6aIoh5/AXFS/iRFIrKKG4aTbSlBialmaTKDxvFGn2m89riAvZKLq
Ogyh3qesmxF53Z0HIOmOTNuayOJIxG4M6t3h+Gq6WfUZrwpTT7cpQscVIIBKthjFOlzT
+cgQ==
X-Gm-Message-State: AGi0PuZ7CiNFoC0GEypzGlILasvZK0r7PRYOWYmo9qNm9cLaCV8gCf4N
2ydDmNafN+WY7cTnttqkq0E44ex8FYmSm5o8GR+vnG2zLw==
X-Google-Smtp-Source: APiQypJen0o7sOA3W1lPpDhqnMjvD4QnHGtHcb5WRPZlChOGzTfxWZ0pb0DmFbMw3XiZXFKlxUgGzZgiOouQ9yUp38U=
X-Received: by 2002:a50:d61c:: with SMTP id x28mr5110755edi.344.1585868188753;
Thu, 02 Apr 2020 15:56:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
<20200331103508.asvxujkhtifj6n7i@ganymede>
<CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
In-Reply-To: <CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Thu, 2 Apr 2020 23:56:17 +0100
Message-ID: <CAJvkSseMqFUJD7rj1AAZPMy0Hf6tufkvrHFgzsViPEirWMWx_A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000d302b05a256b6ef"
X-Mailman-Approved-At: Fri, 03 Apr 2020 00:22:24 +0000
Subject: Re: [bitcoin-dev] Statechain implementations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Thu, 02 Apr 2020 22:56:32 -0000
--0000000000000d302b05a256b6ef
Content-Type: text/plain; charset="UTF-8"
Thanks for all of the input and comments - I do now think that the
decrementing nSequence relative locktime backup system with kick-off
transaction is the way to go, including a fee penalty via CPFP to
disincentivise DoS, as suggested.
I have started a more detailed document specifying the proposed protocol in
more detail:
https://github.com/commerceblock/mercury/blob/master/statechains.md which
includes improvements to the transfer mechanism (and an explanation of how
this can be used to transfer/novate positions in DLCs). Always happy to get
more feedback or PRs.
Tom
On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <tom@commerceblock.com>
wrote:
> Hi David,
>
> Just for clarity, I left nChain over 2 years ago (having worked there
> since 2016). While there, I (along with other researchers) were given free
> rein to work on any ideas we wanted to. I had been interested in the
> scaling of Bitcoin off-chain, and this was one of several things I spent
> time on (including things like sidechains, pegs and threshold signatures).
> This patent application came out of an idea I had to transfer ownership of
> UTXOs off-chain that has some similarities to the statechains proposal,
> which has shown there is interest and demand for this type of system.
>
> Although I think the existence of this application is something to be
> mindful of, there are several important things to note:
>
> 1. Although there are similarities, the current ideas are significantly
> different to those in the application.
> 2. The key transfer protocol as described in the application is not secure
> (for several reasons, including as discussed above, by Albert and Bob etc.)
> - and a different mechanism is required.
> 3. Decrementing timelocks (as suggested in the application) are prior art
> (Decker-Wattenhofer 2015), and in any case any implementation will most
> likely use an 'invalidation tree' relative locktime backup mechanism for
> open-ended UTXOs.
> 4. The patent application has not been granted (it was made in May 2017)
> and the international search report rejected it on the grounds of prior
> art.
>
> Tom
>
> On Tue, Mar 31, 2020 at 11:36 AM David A. Harding <dave@dtrt.org> wrote:
>
>> On Wed, Mar 25, 2020 at 01:52:10PM +0000, Tom Trevethan via bitcoin-dev
>> wrote:
>> > Hi all,
>> >
>> > We are starting to work on an implementation of the statechains concept
>> (
>> >
>> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
>> ),
>> >
>> > [...]
>> > There are two main modifications we are looking at:
>> > [...]
>> >
>> > 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE
>> key
>> > and transitory key) with a single P2(W)PKH output where the public key
>> > shared between the SE and the current owner. The SE and the current
>> owner
>> > can then sign with a 2-of-2 ECDSA MPC.
>>
>> Dr. Trevethan,
>>
>> Would you be able to explain how your proposal to use statechains with
>> 2P-ECDSA relates to your patent assigned to nChain Holdings for "Secure
>> off-chain blockchain transactions"?[1]
>>
>> [1] https://patents.google.com/patent/US20200074464A1
>>
>> Here are some excerpts from the application that caught my attention in
>> the context of statechains in general and your proposal to this list in
>> particular:
>>
>> > an exchange platform that is trusted to implement and operate the
>> > transaction protocol, without requiring an on-chain transaction. The
>> > off-chain transactions enable one computer system to generate multiple
>> > transactions that are recordable to a blockchain in different
>> > circumstances
>> >
>> > [...]
>> >
>> > at least some of the off-chain transactions are valid for recording on
>> > the blockchain even in the event of a catastrophic failure of the
>> > exchange (e.g., exchange going permanently off-line or loosing key
>> > shares).
>> >
>> > [...]
>> >
>> > there may be provided a computer readable storage medium including a
>> > two-party elliptic curve digital signature algorithm (two-party ECDSA)
>> > script comprising computer executable instructions which, when
>> > executed, configure a processor to perform functions of a two-party
>> > elliptic curve digital signature algorithm described herein.
>> >
>> > [...]
>> >
>> > In this instance the malicious actor would then also have to collude
>> > with a previous owner of the funds to recreate the full key. Because
>> > an attack requires either the simultaneous theft of both exchange and
>> > depositor keys or collusion with previous legitimate owners of funds,
>> > the opportunities for a malicious attacker to compromise the exchange
>> > platform are limited.
>>
>> Thank you,
>>
>> -Dave
>>
>
--0000000000000d302b05a256b6ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for all of the input and comments - I do now think =
that the decrementing nSequence relative locktime backup system with kick-o=
ff transaction is the way to go, including a fee penalty via CPFP to disinc=
entivise=C2=A0DoS, as suggested.=C2=A0<div>I have started a more detailed d=
ocument specifying the proposed protocol in more detail:=C2=A0<a href=3D"ht=
tps://github.com/commerceblock/mercury/blob/master/statechains.md">https://=
github.com/commerceblock/mercury/blob/master/statechains.md</a>=C2=A0which =
includes improvements to the transfer=C2=A0mechanism (and an explanation of=
how this can be used to transfer/novate positions in DLCs). Always happy t=
o get more feedback or PRs.=C2=A0</div><div><br></div><div>Tom</div></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue,=
Mar 31, 2020 at 12:41 PM Tom Trevethan <<a href=3D"mailto:tom@commerceb=
lock.com">tom@commerceblock.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi David,<div><br></div><=
div>Just for clarity, I left nChain over 2 years ago (having worked there s=
ince 2016). While there, I (along with other researchers) were given free r=
ein to work on any ideas we wanted to. I had been interested in the scaling=
of Bitcoin off-chain, and this was one of several things I spent time on (=
including things like sidechains,=C2=A0pegs and threshold signatures). This=
patent application came out of an idea I had to transfer ownership of UTXO=
s off-chain that has some similarities to the statechains proposal, which h=
as shown there is interest and demand for this type of system.=C2=A0</div><=
div><br></div><div>Although I think the existence of this application is so=
mething to be mindful of, there are several important things to note:</div>=
<div><br></div><div>1. Although there are similarities, the current ideas a=
re significantly different to those in the application.=C2=A0</div><div>2. =
The key transfer protocol as described in the application is not secure (fo=
r several reasons, including as discussed above, by Albert and Bob etc.) - =
and a different mechanism is required.=C2=A0</div><div>3. Decrementing time=
locks (as suggested in the application) are prior art (Decker-Wattenhofer 2=
015), and in any case any implementation will most likely use an 'inval=
idation tree' relative locktime backup mechanism for open-ended UTXOs.=
=C2=A0</div><div>4. The patent application has not been granted (it was mad=
e in May 2017) and the international search report rejected it on the groun=
ds of prior art.=C2=A0</div><div><br></div><div>Tom</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 31, 20=
20 at 11:36 AM David A. Harding <<a href=3D"mailto:dave@dtrt.org" target=
=3D"_blank">dave@dtrt.org</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">On Wed, Mar 25, 2020 at 01:52:10PM +0000, Tom Trev=
ethan via bitcoin-dev wrote:<br>
> Hi all,<br>
> <br>
> We are starting to work on an implementation of the statechains concep=
t (<br>
> <a href=3D"https://medium.com/@RubenSomsen/statechains-non-custodial-o=
ff-chain-bitcoin-transfer-1ae4845a4a39" rel=3D"noreferrer" target=3D"_blank=
">https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitco=
in-transfer-1ae4845a4a39</a>),<br>
><br>
> [...]<br>
> There are two main modifications we are looking at:<br>
> [...]<br>
> <br>
> 2. Replacing the 2-of-2 multisig output (paying to statechain entity S=
E key<br>
> and transitory key) with a single P2(W)PKH output where the public key=
<br>
> shared between the SE and the current owner. The SE and the current ow=
ner<br>
> can then sign with a 2-of-2 ECDSA MPC. <br>
<br>
Dr. Trevethan,<br>
<br>
Would you be able to explain how your proposal to use statechains with<br>
2P-ECDSA relates to your patent assigned to nChain Holdings for "Secur=
e<br>
off-chain blockchain transactions"?[1]=C2=A0 <br>
<br>
=C2=A0 =C2=A0 [1] <a href=3D"https://patents.google.com/patent/US2020007446=
4A1" rel=3D"noreferrer" target=3D"_blank">https://patents.google.com/patent=
/US20200074464A1</a><br>
<br>
Here are some excerpts from the application that caught my attention in<br>
the context of statechains in general and your proposal to this list in<br>
particular:<br>
<br>
> an exchange platform that is trusted to implement and operate the<br>
> transaction protocol, without requiring an on-chain transaction. The<b=
r>
> off-chain transactions enable one computer system to generate multiple=
<br>
> transactions that are recordable to a blockchain in different<br>
> circumstances<br>
><br>
> [...]<br>
><br>
> at least some of the off-chain transactions are valid for recording on=
<br>
> the blockchain even in the event of a catastrophic failure of the<br>
> exchange (e.g., exchange going permanently off-line or loosing key<br>
> shares).<br>
><br>
> [...]<br>
><br>
> there may be provided a computer readable storage medium including a<b=
r>
> two-party elliptic curve digital signature algorithm (two-party ECDSA)=
<br>
> script comprising computer executable instructions which, when<br>
> executed, configure a processor to perform functions of a two-party<br=
>
> elliptic curve digital signature algorithm described herein.<br>
><br>
> [...]<br>
><br>
> In this instance the malicious actor would then also have to collude<b=
r>
> with a previous owner of the funds to recreate the full key. Because<b=
r>
> an attack requires either the simultaneous theft of both exchange and<=
br>
> depositor keys or collusion with previous legitimate owners of funds,<=
br>
> the opportunities for a malicious attacker to compromise the exchange<=
br>
> platform are limited.<br>
<br>
Thank you,<br>
<br>
-Dave<br>
</blockquote></div>
</blockquote></div>
--0000000000000d302b05a256b6ef--
|