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
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
|
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 7EC4EC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Apr 2020 21:26:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 6824A2281E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Apr 2020 21:26:08 +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 gRC-0zpDi8t6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Apr 2020 21:26:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
[209.85.208.50])
by silver.osuosl.org (Postfix) with ESMTPS id 18229227FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Apr 2020 21:26:05 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id i7so16675703edq.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Apr 2020 14:26:04 -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
:cc; bh=/IOWhnlTrUk1ONLc9+LlLZcYpaVT8reUvBzPvKiD5pk=;
b=z5cSmlCAeifglS6LesnbTlLfKtV7mg3GFPH1mzsDQGRewlbB3k6GtrWrm04AlJ3nrO
HMLBjRWn6YTUVumpQw0QqhKL0i9YOu5IekfMvPTnK0+VZDeUAlpXXUiIUClU98MRDU1T
ULZO+6Wf4nJmDTYvxdY9Xz7m87XeX//ZM7fVjo2MKdJ6hod42KATLUJr0UVbBFUrk/b/
snIfBwzq6AprdW3tqmgdXMLZXdUCMuMIzAdk50/SYZQ2scrcknz1kP/QxMntL5yVsrcg
jW+ffoGMmX56X1A2xKpy7VpZqGpeNlrIHb49EIb8EobjNvJBBB4b8Hv9KNamVZVHv+w+
MNDw==
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:cc;
bh=/IOWhnlTrUk1ONLc9+LlLZcYpaVT8reUvBzPvKiD5pk=;
b=mFieVkPs0iV9nXyUj1E93BM6i2VyRQfdLcE5fqfntEfDLOTKtrG+L/S9Wp0mfEHy0d
iv/UOciExOq0jzT+F46+tpy7SJ7l9/fHQo5xQ6mu/IUrQIEYPx4QSTf0NXDX2jKz+RbJ
FL1mQlfdMqqgochnExdJhYikidbquIwk4Q6g4CH6rZx1vTANNQEGKmlUVhMQFrBmv7/A
u7t2oZiV6JvmtRPjzCK2LcWn1FpwUwot9xDDrmeG60to4WHKwfcgmg3QyN4LgOCdCNpw
R7s9nRfP0gp7CCEnFo8jQbU/YotQ9HOhkYPhR7NMrCvvs4uLo/FYR9Rg851LHSlo66Gh
pKog==
X-Gm-Message-State: AGi0PuZQzdrmtObI7mkEhh0Eda/YkGBdZWuuA6v+NXQtSKbXhQd/P6YV
49OFrp60yvu8M1ZNRL+Mv9b9dVxUiHpNnv27kPbd
X-Google-Smtp-Source: APiQypK+m9oaVabGLTOPJ6F0TnbUdL4dd6pn6BXLENqX5V0fMn0JT676FWTciFxEUoXIK+hmphebAcCwcdzLBFWBHso=
X-Received: by 2002:a50:d24c:: with SMTP id o12mr16819112edg.219.1586121963149;
Sun, 05 Apr 2020 14:26:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
<20200331103508.asvxujkhtifj6n7i@ganymede>
<CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
<CAJvkSseMqFUJD7rj1AAZPMy0Hf6tufkvrHFgzsViPEirWMWx_A@mail.gmail.com>
<CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com>
<20200405141717.GN28113@mcelrath.org>
In-Reply-To: <20200405141717.GN28113@mcelrath.org>
From: Tom Trevethan <tom@commerceblock.com>
Date: Sun, 5 Apr 2020 22:25:51 +0100
Message-ID: <CAJvkSsf2UxDAkxMC4MuedP2xcgM4_aDQNQfofeW7MBh2oK73rw@mail.gmail.com>
To: Bob McElrath <bob@mcelrath.org>
Content-Type: multipart/alternative; boundary="0000000000002f2c4105a291cc13"
X-Mailman-Approved-At: Sun, 05 Apr 2020 22:55:22 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 05 Apr 2020 21:26:08 -0000
--0000000000002f2c4105a291cc13
Content-Type: text/plain; charset="UTF-8"
Hi Bob and Nadav,
There seems to be no way to prevent a malicious SE from stealing an
output from the current owner by either colluding with (or being) a
previous owner. But with a proof-of-publication (i.e. the statechain) it is
possible for the current owner to have a proof that the SE has stolen from
them. It seems to me that the statechain itself provides two functions: 1.
Proof that an output has only a single owner at any time (preventing the SE
from double-spending) and 2. a way for the current owner to prove their
ownership, and require their permission to change ownership. 1. can just be
a publication by the SE, but 2. requires that the output is transferred to
a public key of the owner, and only via a signature of the previous owner
(in this way the SE cannot re-assign ownership unilaterally). Therefore I
think Nadav is right, and this needs to be a key that the SE can never know
(even if they are malicious), but which can be used to prove ownership, and
in turn prove fraud on the part of the SE.
I don't think that this should be too much of an issue: any wallet will
have to use new keys for each output and transfer anyway. The statechain
key (used for the ownership proof) and the output key share can be on
different hardened HD paths (following on from a path derived from the
outpoint of the UTXO, similar to the method in BIP175).
Tom
On Sun, Apr 5, 2020 at 3:17 PM Bob McElrath <bob@mcelrath.org> wrote:
> Note that this attack requires collaboration with the current UTXO owner.
> Generally if there's some form of address/payment request, the current
> holder is
> trying to transfer the UXTO to some other (non-statechain) entity, and he
> knows
> the target of the transfer, and participates in the protocol to authorize
> it.
> The current holder must obtain the target pubkey for the transfer
> out-of-band
> with respect to the SE, or the SE can MITM that.
>
> It's a stated security assumption that the sender or receiver do not
> collude
> with the SE. If either do, then your attack is generally possible and all
> bets
> are off. So what you've described is simply the SE colluding with the
> receiver.
> The receiver will *already* receive the UTXO, so the receiver here is
> assisting
> the SE in stealing his (the receiver's) funds, or the SE has done a MITM
> on the
> transfer. Various improvements including blind signing, a SE-federation,
> etc
> are valuable to consider to mitigate this. But the SE must be prevented,
> one way
> or another, from "buying the UTXO". The SE cannot be allowed to be both
> operator
> of the SE and a customer of it, as this clearly violates the no-receiver
> collusion principle.
>
> "Adding a new user key" doesn't change the situation. There's already a
> user key
> involved, and the user has already acquiesced to the transfer. Acquiescing
> with
> two keys doesn't change anything.
>
> As far as proving and tracing the fraud, this is where "single use seals"
> come
> in. Each SE transfer can involve an "opening" of a seal, followed by a
> "close"
> when it is transferred, creating a linear history of ownership. If the SE
> obtains the full private key x, one way or another, the spend of that UTXO
> will
> fall outside this seal-based history, and proof of fraud will be evident.
> It
> won't be possible to determine *which* of the old owners collaborated with
> the
> SE, but it gives clear proof that the SE is not to be trusted. A customer
> might
> demand that a seal-based system be in use as an independent entity from
> the SE,
> to audit the honesty of the SE. The seal system does not require any of
> the keys
> required for transfer. See https://mainstay.xyz as a potential
> implementation.
> There are lots of reasons this might required as an AML solution for some
> businesses anyway.
>
> Nadav Kohen via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote:
> > Hey all,
> >
> > So my main concern with the proposal as written is that the Statechain
> Entity
> > (SE) can untraceably scam its users with the following attack:
> >
> > 1) Buy the utxo (have it transferred to a key it knows), this first step
> can be
> > skipped if the utxo was created by the SE.
> > 2) Transfer the UTXO to someone else, let it be for however long
> > 3) When it wishes to steal the UTXO, the SE now knows its own shard s_n
> and it
> > knows the full private key, x, from when it owned the UTXO (and had both
> > shards), and so it can compute x/s_n = the current users shard. It can
> then
> > sign for the current user, and forge a state transition to a key it owns
> before
> > spending the UTXO on chain.
> >
> > The main problem here is that the user who had their funds stolen cannot
> prove
> > to anyone that this has happened since the attack compromises their key.
> > That said, I think this problem is easily fixed by adding a new user key
> to the
> > protocol with which they must sign in order for the transfer to be
> considered
> > valid on the state chain. This way, if the SE wishes to steal the funds
> (which
> > they still can), at least it is traceable/provable that this SE is not
> > trustworthy as there is no evidence of a valid transfer for the funds
> that have
> > been stolen.
> >
> > Best,
> > Nadav
> >
> > On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > 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
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > !DSPAM:5e87670a231323960034969!
>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > !DSPAM:5e87670a231323960034969!
>
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
> -- H. L. Mencken
>
>
--0000000000002f2c4105a291cc13
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Bob and Nadav,<div><br></div><div>There seems to be no =
way to prevent a malicious SE from stealing an output=C2=A0from the current=
owner=C2=A0by either colluding with (or=C2=A0being) a previous owner. But =
with a proof-of-publication (i.e. the statechain) it is possible for the cu=
rrent owner to have a proof that the SE has stolen from them. It=C2=A0seems=
to me that the statechain itself provides two functions: 1. Proof that an =
output has only a single owner at any time (preventing the SE from double-s=
pending) and 2. a way for the current owner to prove their ownership, and r=
equire their permission to change ownership. 1. can just be a publication b=
y the SE, but 2. requires that the output is transferred=C2=A0to a public k=
ey of the owner, and only via a signature of the previous owner (in this wa=
y the SE cannot re-assign ownership unilaterally). Therefore I think Nadav =
is right, and this needs to be a key that the SE can never know (even if th=
ey are malicious), but which can be used to prove ownership, and in turn pr=
ove fraud on the part of the SE.=C2=A0</div><div><br></div><div>I don't=
think that this should be too much of an issue: any wallet will have to us=
e new keys for each output and transfer anyway. The statechain key (used fo=
r the ownership proof) and the output key share can be on different hardene=
d HD paths (following on from a path derived from the outpoint of the UTXO,=
similar to the method in BIP175).=C2=A0</div><div><br></div><div>Tom</div>=
<div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sun, Apr 5, 2020 at 3:17 PM Bob McElrath &=
lt;<a href=3D"mailto:bob@mcelrath.org" target=3D"_blank">bob@mcelrath.org</=
a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No=
te that this attack requires collaboration with the current UTXO owner.<br>
Generally if there's some form of address/payment request, the current =
holder is<br>
trying to transfer the UXTO to some other (non-statechain) entity, and he k=
nows<br>
the target of the transfer, and participates in the protocol to authorize i=
t.<br>
The current holder must obtain the target pubkey for the transfer out-of-ba=
nd<br>
with respect to the SE, or the SE can MITM that.<br>
<br>
It's a stated security assumption that the sender or receiver do not co=
llude<br>
with the SE. If either do, then your attack is generally possible and all b=
ets<br>
are off. So what you've described is simply the SE colluding with the r=
eceiver.<br>
The receiver will *already* receive the UTXO, so the receiver here is assis=
ting<br>
the SE in stealing his (the receiver's) funds, or the SE has done a MIT=
M on the<br>
transfer.=C2=A0 Various improvements including blind signing, a SE-federati=
on, etc<br>
are valuable to consider to mitigate this. But the SE must be prevented, on=
e way<br>
or another, from "buying the UTXO". The SE cannot be allowed to b=
e both operator<br>
of the SE and a customer of it, as this clearly violates the no-receiver<br=
>
collusion principle.<br>
<br>
"Adding a new user key" doesn't change the situation. There&#=
39;s already a user key<br>
involved, and the user has already acquiesced to the transfer. Acquiescing =
with<br>
two keys doesn't change anything.<br>
<br>
As far as proving and tracing the fraud, this is where "single use sea=
ls" come<br>
in. Each SE transfer can involve an "opening" of a seal, followed=
by a "close"<br>
when it is transferred, creating a linear history of ownership. If the SE<b=
r>
obtains the full private key x, one way or another, the spend of that UTXO =
will<br>
fall outside this seal-based history, and proof of fraud will be evident. I=
t<br>
won't be possible to determine *which* of the old owners collaborated w=
ith the<br>
SE, but it gives clear proof that the SE is not to be trusted. A customer m=
ight<br>
demand that a seal-based system be in use as an independent entity from the=
SE,<br>
to audit the honesty of the SE. The seal system does not require any of the=
keys<br>
required for transfer. See <a href=3D"https://mainstay.xyz" rel=3D"noreferr=
er" target=3D"_blank">https://mainstay.xyz</a> as a potential implementatio=
n.<br>
There are lots of reasons this might required as an AML solution for some<b=
r>
businesses anyway.<br>
<br>
Nadav Kohen via bitcoin-dev [<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>] wro=
te:<br>
> Hey all,<br>
> <br>
> So my main concern with the proposal as written is that the Statechain=
Entity<br>
> (SE) can untraceably=C2=A0scam its users with the following attack:<br=
>
> <br>
> 1) Buy the utxo (have it transferred to a key it knows), this first st=
ep can be<br>
> skipped if the utxo was created by the SE.<br>
> 2) Transfer the UTXO to someone else, let it be for however long<br>
> 3) When it wishes to steal the UTXO, the SE now knows its own shard s_=
n and it=C2=A0<br>
> knows the full private key, x, from when it owned the UTXO (and had bo=
th<br>
> shards), and so it can compute x/s_n =3D the current users shard. It c=
an then<br>
> sign for the current user, and forge a state transition to a key it ow=
ns before<br>
> spending the UTXO on chain.<br>
> <br>
> The main problem here is that the user who had their funds stolen cann=
ot prove<br>
> to anyone that this has happened since the attack compromises their ke=
y.<br>
> That said, I think this problem is easily fixed by adding a new user k=
ey to the<br>
> protocol with which they must sign in order for the transfer to be con=
sidered<br>
> valid on the state chain. This way, if the SE wishes to steal the fund=
s (which<br>
> they still can), at least it is traceable/provable that this SE is not=
<br>
> trustworthy as there is no evidence of a valid transfer for the funds =
that have<br>
> been stolen.<br>
> <br>
> Best,<br>
> Nadav<br>
> <br>
> On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev <<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0Thanks for all of the input and comments - I do now=
think that the<br>
>=C2=A0 =C2=A0 =C2=A0decrementing nSequence relative locktime backup sys=
tem with kick-off<br>
>=C2=A0 =C2=A0 =C2=A0transaction is the way to go, including a fee penal=
ty via CPFP to<br>
>=C2=A0 =C2=A0 =C2=A0disincentivise=C2=A0DoS, as suggested.=C2=A0<br>
>=C2=A0 =C2=A0 =C2=A0I have started a more detailed document specifying =
the proposed protocol in<br>
>=C2=A0 =C2=A0 =C2=A0more detail:=C2=A0<a href=3D"https://github.com/com=
merceblock/mercury/blob/master/" rel=3D"noreferrer" target=3D"_blank">https=
://github.com/commerceblock/mercury/blob/master/</a><br>
>=C2=A0 =C2=A0 =C2=A0statechains.md=C2=A0which includes improvements to =
the transfer=C2=A0mechanism (and<br>
>=C2=A0 =C2=A0 =C2=A0an explanation of how this can be used to transfer/=
novate positions in<br>
>=C2=A0 =C2=A0 =C2=A0DLCs). Always happy to get more feedback or PRs.=C2=
=A0<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0Tom<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <=
<a href=3D"mailto:tom@commerceblock.com" target=3D"_blank">tom@commercebloc=
k.com</a>><br>
>=C2=A0 =C2=A0 =C2=A0wrote:<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi David,<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just for clarity, I left nChain over =
2 years ago (having worked there<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0since 2016). While there, I (along wi=
th other researchers) were given<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0free rein to work on any ideas we wan=
ted to. I had been interested in<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the scaling of Bitcoin off-chain, and=
this was one of several things I<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spent time on (including things like =
sidechains,=C2=A0pegs and threshold<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures). This patent application =
came out of an idea I had to<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transfer ownership of UTXOs off-chain=
that has some similarities to the<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statechains proposal, which has shown=
there is interest and demand for<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this type of system.=C2=A0<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Although I think the existence of thi=
s application is something to be<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mindful of, there are several importa=
nt things to note:<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Although there are similarities, t=
he current ideas are significantly<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different to those in the application=
.=C2=A0<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. The key transfer protocol as descr=
ibed in the application is not<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0secure (for several reasons, includin=
g as discussed above, by Albert<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Bob etc.) - and a different mecha=
nism is required.=C2=A0<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. Decrementing timelocks (as suggest=
ed in the application) are prior<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0art (Decker-Wattenhofer 2015), and in=
any case any implementation will<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0most likely use an 'invalidation =
tree' relative locktime backup<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism for open-ended UTXOs.=C2=A0=
<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04. The patent application has not bee=
n granted (it was made in May<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02017) and the international search re=
port rejected it on the grounds of<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prior art.=C2=A0<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tom<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Mar 31, 2020 at 11:36 AM Davi=
d A. Harding <<a href=3D"mailto:dave@dtrt.org" target=3D"_blank">dave@dt=
rt.org</a>><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, Mar 25, 2020 at=
01:52:10PM +0000, Tom Trevethan via<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev wrote:<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi all,<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> We are starting to=
work on an implementation of the statechains<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0concept (<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> <a href=3D"https:/=
/medium.com/@RubenSomsen/" rel=3D"noreferrer" target=3D"_blank">https://med=
ium.com/@RubenSomsen/</a><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statechains-non-custodi=
al-off-chain-bitcoin-transfer-1ae4845a4a39),<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> There are two main=
modifications we are looking at:<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> 2. Replacing the 2=
-of-2 multisig output (paying to statechain<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entity SE key<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> and transitory key=
) with a single P2(W)PKH output where the<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public key<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> shared between the=
SE and the current owner. The SE and the<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current owner<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> can then sign with=
a 2-of-2 ECDSA MPC.<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dr. Trevethan,<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would you be able to ex=
plain how your proposal to use statechains<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02P-ECDSA relates to you=
r patent assigned to nChain Holdings for<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Secure<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0off-chain blockchain tr=
ansactions"?[1]=C2=A0<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 [1] <a hr=
ef=3D"https://patents.google.com/patent/US20200074464A1" rel=3D"noreferrer"=
target=3D"_blank">https://patents.google.com/patent/US20200074464A1</a><br=
>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Here are some excerpts =
from the application that caught my<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attention in<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the context of statecha=
ins in general and your proposal to this<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list in<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular:<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> an exchange platfo=
rm that is trusted to implement and operate the<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> transaction protoc=
ol, without requiring an on-chain transaction.<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> off-chain transact=
ions enable one computer system to generate<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> transactions that =
are recordable to a blockchain in different<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> circumstances<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> at least some of t=
he off-chain transactions are valid for<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recording on<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the blockchain eve=
n in the event of a catastrophic failure of the<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> exchange (e.g., ex=
change going permanently off-line or loosing<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> shares).<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> there may be provi=
ded a computer readable storage medium<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including a<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> two-party elliptic=
curve digital signature algorithm (two-party<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ECDSA)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> script comprising =
computer executable instructions which, when<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> executed, configur=
e a processor to perform functions of a<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0two-party<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> elliptic curve dig=
ital signature algorithm described herein.<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> In this instance t=
he malicious actor would then also have to<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0collude<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> with a previous ow=
ner of the funds to recreate the full key.<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Because<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> an attack requires=
either the simultaneous theft of both exchange<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> depositor keys or =
collusion with previous legitimate owners of<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0funds,<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the opportunities =
for a malicious attacker to compromise the<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exchange<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> platform are limit=
ed.<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you,<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-Dave<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________<br>
>=C2=A0 =C2=A0 =C2=A0bitcoin-dev mailing list<br>
>=C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
>=C2=A0 =C2=A0 =C2=A0<a href=3D"https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
> <br>
> !DSPAM:5e87670a231323960034969!<br>
<br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
> <br>
> <br>
> !DSPAM:5e87670a231323960034969!<br>
<br>
--<br>
Cheers, Bob McElrath<br>
<br>
"For every complex problem, there is a solution that is simple, neat, =
and wrong."<br>
=C2=A0 =C2=A0 -- H. L. Mencken <br>
<br>
</blockquote></div>
--0000000000002f2c4105a291cc13--
|