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
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 77A7CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Apr 2022 02:09:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 7049A417E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Apr 2022 02:09:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id kgujbyid8SEY
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Apr 2022 02:09:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
[IPv6:2a00:1450:4864:20::630])
by smtp4.osuosl.org (Postfix) with ESMTPS id 156B1417DF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Apr 2022 02:09:20 +0000 (UTC)
Received: by mail-ej1-x630.google.com with SMTP id kq17so602648ejb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Apr 2022 19:09:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=LxI4XJTsQd2GadHF7i3HmXm75NP2vBF0tt+UA9mEXDE=;
b=dGDYTzg0lDNI/DnrhgT1cAVCwh4WU/kw+31nwpj55cG4PfMZFx2V9ajZ+HujqOORG3
BlKwJmTGRCw6RrHnfzS5Cf6yrWhCjwGae0bnf8s95QsXCVWwtlfEdqpb7r6IstdrPi1x
kIMRxWsZwSKz54eOACN9A+MEpvQChSZ56F1yycqYE2wiPaFkewMM+yIr9vkQm2ECA6y+
7RDxVWSX6RQysXpf6DSaPVz/0iWwkBllRVpxoLs7Rwk4bU8Oxe9iliVEDkhWTeVf7LYW
37TiWtZyiWgg6yLw9TKTvfW3xqrq4MwPUGHjXMDzm0AB3xkpHzZ9Uo5RBv2xGn5xel17
1YhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=LxI4XJTsQd2GadHF7i3HmXm75NP2vBF0tt+UA9mEXDE=;
b=YVxwONQX7ukN9HCqftyj0ifmh35fjKQMWy6glsj5QgQcrPfGaqYPafXhgZOZrDRzO5
whOEJHITxcJIdw8NkVR9YyyUz2kBWjsEaL/Ks5910bnPZPEvhaI0FgnzJxECR3uPralT
gOnbC7oMwVxbUSg8QSUukoi+7AeBg5hoiHQsuGR5MBPbr0PiFLjfXshfPi01AUGyHYKN
8UdvkArSWoLseyGhc4134cneEdTu8st8KNeHICH2IRBALxhC6fJLlZ0i0wlBuvNZepeF
pg+dSailQIcDPCKI6akuFrFIr0S6vwGy5AkQAyVyRYg6djwayuJt9Fi4JIQ+iwL0VH3z
62qQ==
X-Gm-Message-State: AOAM532eCHv9bpbjmtInvmgUk3C5IWeZG67MoQTWjhI69N2Oj0X3YA0l
1C5wSpQdHh2XaiZ8dk0PH8qLfG7Rsu1mpI85La7RxDm1qjM=
X-Google-Smtp-Source: ABdhPJyUJQ+RGJV0PC6VJOhb6HS6poe8KKJK6+SwQN6ljoi9SNFH2bbw0VKg1QBLrwlfkDh1TkAFHXkTB4mK8OZycOk=
X-Received: by 2002:a17:907:3daa:b0:6e8:969d:564d with SMTP id
he42-20020a1709073daa00b006e8969d564dmr23601147ejc.735.1651025358856; Tue, 26
Apr 2022 19:09:18 -0700 (PDT)
MIME-Version: 1.0
References: <cn2quZuZeFKn3KjA0y3LaSTi9DIaFywY7dYdAfDnJqL7StqG6ljplYmNi-7sQ11J-_PR--FLAFMrqViqIqiBU9BWf8t5kO2zDRknwPyNfY0=@protonmail.com>
In-Reply-To: <cn2quZuZeFKn3KjA0y3LaSTi9DIaFywY7dYdAfDnJqL7StqG6ljplYmNi-7sQ11J-_PR--FLAFMrqViqIqiBU9BWf8t5kO2zDRknwPyNfY0=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 26 Apr 2022 21:09:03 -0500
Message-ID: <CAGpPWDbMB9aT4rqAG-4RnWRZuLpeesZ7JHydtYgT5ohNNy_VHw@mail.gmail.com>
To: Buck O Perley <buck.perley@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000007a69405dd994c71"
X-Mailman-Approved-At: Wed, 27 Apr 2022 08:09:15 +0000
Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
("transitory") > soft forks)
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: Wed, 27 Apr 2022 02:09:23 -0000
--00000000000007a69405dd994c71
Content-Type: text/plain; charset="UTF-8"
> the hot wallet can only spend a certain amount from the hot wallet spend
and the rest would .. be sent back
That would definitely be the way to do it. The ability to steal from the
hot wallet in my opinion shouldn't really be a "concern" about CTV, but
rather an understood tradeoff of a CTV wallet vault. In fact, its hardly
even a trade off - a CTV vault can be created that is usable exactly as a
normal multisig wallet if the user wants to use it that way. The unvaulting
would simply add an additional (and optional) usability improvement over
normal multisig. The security considerations around choosing the
appropriate maximum amount to unvault at a time (with one key) is just
something that someone would need to decide based on basically their
comfort level. It sounds like you said something very similar in your point
2.
Would I like to have a wallet vault that doesn't have this security
consideration? Sure. But that isn't to say a wallet vault with that hitch
isn't a very useful advance to self-custody setups.
> You also get the nice benefit of learning about compromised keys without
having to risk all funds associated with that key.
This is an interesting tack-on attribute. A built in honey pot. If you only
allow 1% of your savings to be taken out at a time (with one key), is 1% of
your savings worth knowing that your wallet has been partially compromised?
Maybe it would be.
On Mon, Apr 25, 2022 at 11:51 AM Buck O Perley via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Just a couple of comments re-CTV vault security concerns.
>
>
> 1. One way to assuage the concern of the hot wallet vulnerability
> is pre-program the spends such that the hot wallet can only
> spend a certain amount from the hot wallet spend and the rest would
> kind of be "recursive" in that it would be sent back to a
> new instantiation of the CTV vault. I believe kanzure's vaults
> does this w/ the non-covenant version using pre-signed transactions
> (https://github.com/kanzure/python-vaults). While this doesn't
> prevent the theft it caps off the total risk. I would argue that
> this is strictly better than a multisig because you can also use
> multisig as you normally would if you want but you have the option
> if you think your hot key is secure to use that spending path.
> You also get the nice benefit of learning about compromised
> keys without having to risk all funds associated with that key.
>
>
> 2. As to how to improve UX for CTV with other proposals, I think
> you get a lot of benefits when using with taproot because you can
> use CTV in tapleaves to secure specific spend conditions, but can
> always fall back to other off-ramps (e.g. a musig key path spend or
> other script path conditions). Of course you can do this without
> taproot but taproot makes this more space efficient. This idea has
> been used to some effect in some recent exploration of how CTV can
> help improve UX around DLCs. You could even do this to help with
> the problems of not sending the right amount such that you have a
> really really cold key or set of keys for example such that if you
> have UTXOs that have values that can't be spent with the given CTV
> commitment, then you just use that other branch.
>
> - Buck
>
> ------- Original Message -------
>
> > Date: Sun, 24 Apr 2022 18:03:52 -0500
> > From: Billy Tetrud billy.tetrud@gmail.com
> >
>
> > To: "Russell O'Connor" roconnor@blockstream.com, Bitcoin Protocol
> >
>
> > Discussion bitcoin-dev@lists.linuxfoundation.org
> >
>
> > Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
> > ("transitory") soft forks)
> > Message-ID:
> > CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail.gmail.com
> >
>
> > Content-Type: text/plain; charset="utf-8"
> >
>
> > @Matt
> >
>
> > > both of which are somewhat frustrating limitations, but not security
> >
>
> > limitations, only practical ones.
> >
>
> > So I think the first limitation you mentioned (that if your hot wallet's
> > key gets stolen you need) can be legitimately considered a security
> > limitation. Not because you need to rotate your keys, but because you
> might
> > not know your hot wallet key has been stolen. If you unvault an output to
> > your hot wallet, the thief could be lying in wait, ready to steal those
> > funds upon them landing. At that point, you would then know your hot
> wallet
> > key was compromised and could rotate your vault keys in order to prevent
> > further theft. However, the fact that there is a clear theft
> vulnerability
> > is something I would say should be considered a "security limitation".
> >
>
> > As you mentioned, this is of course also a security limitation of a hot
> > wallet, so this setup definitely has a lot of advantages over a simple
> hot
> > wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
> > you can see that while theft of a single key would never result in any
> > theft in that setup, it could in a CTV vault. The other trade offs there
> > are ones of practicality and convenience.
> >
>
> > This isn't to say a CTV vault wouldn't be useful. Just that it has
> > significant trade offs.
> >
>
> > @Russel
> >
>
> > > the original MES vault .. commits to the destination address during
> >
>
> > unvaulting
> >
>
> > I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> > for me to understand that it does that. However, I can imagine how it
> > might do that.
> >
>
> > One possibility is that the intended destination is predetermined and
> > hardcoded. This wouldn't be very useful, and also wouldn't be different
> > than how CTV could do it, so I assume that isn't what you envisioned this
> > doing.
> >
>
> > I can imagine instead that the definition of the pattern could be
> specified
> > as a number indicating the number of stack items in the pattern, followed
> > by that number of stack items. If that's how it is done, I can see the
> user
> > inputting an intended destination script (corresponding to the intended
> > destination address) which would then be somehow rotated in to the right
> > spot within the pattern, allowing the pattern to specify the coins
> > eventually reaching an address with that script. However, this could be
> > quite cumbersome, and would require fully specifying the scripts along
> the
> > covenant pathways leading to a fair amount of information duplication
> > (since scripts must be specified both in the covenant and in spending the
> > subsequent output). Both of these things would seem to make OP_COV in
> > practice quite an expensive opcode to spend with. It also means that,
> since
> > the transactor must fully specify the script, its not possible to take
> > advantage of taproot's script hiding capabilities (were it to send to a
> > taproot address).
> >
>
> > However, my assumptions might be incorrect. If you think OP_COV would be
> a
> > useful opcode, I would encourage you to write up a complete
> specification.
> >
>
> > > What ways can we build a secured vault that commits to the destination
> >
>
> > address?
> >
>
> > Some kind of passed-through state allows doing this. With OP_COV (if my
> > assumptions above are correct), the intended destination can be passed
> > through the output script pattern(s). With my own proposed
> > op_pushoutputstack
> >
> https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md
> ,
> >
>
> > state is passed as an attachment on the output more directly. Curious
> what
> > you think about that proposal.
> >
>
> > > Are there elegant ways of building secure vaults by using CTV plus
> >
>
> > something else.
> >
>
> > Since CTV predefines all the transactions that can happen under its
> > control, passed state like this can't help because any dynamic state
> would
> > change the template and render the CTV transaction invalid. I don't see
> any
> > way of solving this problem for CTV.
> >
>
> > I'm curious how you think op_cat could enable this with CTV (other than
> the
> > cat+schnorr tricks that don't require CTV at all).
> >
>
> >
>
> >
>
> > On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
>
> > > Okay, Matt explained to me the intended application of CTV vaults off
> > > list, so I have a better understanding now.
> > >
>
> > > The CTV vault scheme is designed as an improvement over the traditional
> > > management of hot-wallets and cold-wallets. The CTV vault is logically
> on
> > > the "cold-side" and lets funds be sent from the "cold" side to one's
> own
> > > the hot wallet after the unvaulting delay. In this case, the hot wallet
> > > funds are always at risk, so it isn't unexpected that those funds
> could be
> > > stolen. After all, that is how hot wallets are today. The advantage is
> > > that funds can be moved from the "cold" side without needing to dig
> out the
> > > cold keys.
> > >
>
> > > The MES vault scheme applies to a different scenario. In the MES case
> it
> > > is the hot funds are inside the vault, and it is the hot key that
> unvaults
> > > the funds and sends them to customer's addresses after a delay. If the
> > > hot-key is used in any unauthorised way, then funds can be sent to the
> > > address of the cold key (the MES vault actually does something fancy in
> > > case of recovery, but it could be adapted to simply send funds to a
> cold
> > > wallet).
> > >
>
> > > The MES vault lie somewhere between "better" and "different" when
> compared
> > > to the CTV vault. If one is unwilling to use the MES vault on the hot
> side
> > > and have every withdrawl vetted, then, while you could use the MES
> design
> > > on the cold side like the CTV vault, it wouldn't really offer you any
> > > advantages over a CTV vault. However, if you are interested in managing
> > > all your payments through a vault (as I've been imagining) then the CTV
> > > vault comes across as ineffective when compared to an MES style vault.
> > >
>
> > > On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo lf-lists@mattcorallo.com
> > > wrote:
> > >
>
> > > > Still trying to make sure I understand this concern, let me know if
> I get
> > > > this all wrong.
> > > >
>
> > > > On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > > >
>
> > > > > It's not the attackers only choice to succeed. If an attacker
> steals
> > > > > the hot key, then they have
> > > > > the option to simply wait for the user to unvault their funds of
> their
> > > > > own accord and then race /
> > > > > outspend the users transaction with their own. Indeed, this is
> what we
> > > > > expect would happen in the
> > > > > dark forest.
> > > >
>
> > > > Right, a key security assumption of the CTV-based vaults would be
> that
> > > > you MUST NOT EVER withdraw
> > > > more in one go than your hot wallet risk tolerance, but given that
> your
> > > > attack isn't any worse than
> > > > simply stealing the hot wallet key immediately after a withdraw.
> > > >
>
> > > > It does have the drawback that if you ever get a hot wallet key
> stole you
> > > > have to rotate all of your
> > > > CTV outputs and your CTV outputs must never be any larger than your
> hot
> > > > wallet risk tolerance
> > > > amount, both of which are somewhat frustrating limitations, but not
> > > > security limitations, only
> > > > practical ones.
> > > >
>
> > > > > And that's not even mentioning the issues already noted by the
> document
> > > > > regarding fee management,
> > > > > which would likely also benefit from a less constrained design for
> > > > > covenants.
> > > >
>
> > > > Of course I've always been in favor of a less constrained covenants
> > > > design from day one for ten
> > > > reasons, but that's a whole other rabbit hole :)
> > >
>
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000007a69405dd994c71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0
the hot wallet can only spend a certain amount from the hot wallet spend an=
d the rest would .. be sent back<div><br></div><div>That would definitely b=
e the way to do it. The ability to steal from the hot wallet in my opinion =
shouldn't really be a "concern" about CTV, but rather an unde=
rstood tradeoff of a CTV wallet vault. In fact, its hardly even a trade off=
- a CTV vault can be created that is usable exactly as a normal multisig w=
allet if the user wants to use it that way. The unvaulting would simply add=
an additional (and optional) usability improvement over normal multisig. T=
he security considerations around choosing the appropriate maximum amount t=
o unvault at a time (with one key) is just something that someone would nee=
d to decide based on basically their comfort level. It sounds like you said=
something very similar in your point 2.</div><div><br></div><div>Would I l=
ike to have a wallet vault that doesn't have this security consideratio=
n? Sure. But that isn't to say a wallet vault with that hitch isn't=
a very useful advance to self-custody setups.</div><div><br></div><div>>=
; You also get the nice benefit of learning about compromised keys without =
having to risk all funds associated with that key.</div><div><br></div><div=
>This is an interesting tack-on attribute. A built in honey pot. If you onl=
y allow 1% of your savings to be taken out at a time (with one key), is=C2=
=A01% of your savings worth knowing that your wallet has been partially com=
promised? Maybe it would be.<br><div><br></div><div><br></div></div></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon,=
Apr 25, 2022 at 11:51 AM Buck O Perley via bitcoin-dev <<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">Just a couple of comments re-CTV vault security concerns.<br>
<br>
<br>
1. One way to assuage the concern of the hot wallet vulnerability<br>
is pre-program the spends such that the hot wallet can only<br>
spend a certain amount from the hot wallet spend and the rest would<br>
kind of be "recursive" in that it would be sent back to a<br>
new instantiation of the CTV vault. I believe kanzure's vaults<br>
does this w/ the non-covenant version using pre-signed transactions<br>
(<a href=3D"https://github.com/kanzure/python-vaults" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/kanzure/python-vaults</a>). While this d=
oesn't<br>
prevent the theft it caps off the total risk. I would argue that<br>
this is strictly better than a multisig because you can also use<br>
multisig as you normally would if you want but you have the option<br>
if you think your hot key is secure to use that spending path.<br>
You also get the nice benefit of learning about compromised<br>
keys without having to risk all funds associated with that key.<br>
<br>
<br>
2. As to how to improve UX for CTV with other proposals, I think<br>
you get a lot of benefits when using with taproot because you can<br>
use CTV in tapleaves to secure specific spend conditions, but can<br>
always fall back to other off-ramps (e.g. a musig key path spend or<br>
other script path conditions). Of course you can do this without<br>
taproot but taproot makes this more space efficient. This idea has<br>
been used to some effect in some recent exploration of how CTV can<br>
help improve UX around DLCs. You could even do this to help with<br>
the problems of not sending the right amount such that you have a<br>
really really cold key or set of keys for example such that if you<br>
have UTXOs that have values that can't be spent with the given CTV<br>
commitment, then you just use that other branch.<br>
<br>
- Buck<br>
<br>
------- Original Message -------<br>
<br>
> Date: Sun, 24 Apr 2022 18:03:52 -0500<br>
> From: Billy Tetrud <a href=3D"mailto:billy.tetrud@gmail.com" target=3D=
"_blank">billy.tetrud@gmail.com</a><br>
> <br>
<br>
> To: "Russell O'Connor" <a href=3D"mailto:roconnor@blocks=
tream.com" target=3D"_blank">roconnor@blockstream.com</a>, Bitcoin Protocol=
<br>
> <br>
<br>
> Discussion <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <br>
<br>
> Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting<br>
> ("transitory") soft forks)<br>
> Message-ID:<br>
> <a href=3D"mailto:CAGpPWDaeKYABkK%2BStFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1=
A@mail.gmail.com" target=3D"_blank">CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFj=
Ott9W8UPRr1A@mail.gmail.com</a><br>
> <br>
<br>
> Content-Type: text/plain; charset=3D"utf-8"<br>
> <br>
<br>
> @Matt<br>
> <br>
<br>
> > both of which are somewhat frustrating limitations, but not secur=
ity<br>
> <br>
<br>
> limitations, only practical ones.<br>
> <br>
<br>
> So I think the first limitation you mentioned (that if your hot wallet=
's<br>
> key gets stolen you need) can be legitimately considered a security<br=
>
> limitation. Not because you need to rotate your keys, but because you =
might<br>
> not know your hot wallet key has been stolen. If you unvault an output=
to<br>
> your hot wallet, the thief could be lying in wait, ready to steal thos=
e<br>
> funds upon them landing. At that point, you would then know your hot w=
allet<br>
> key was compromised and could rotate your vault keys in order to preve=
nt<br>
> further theft. However, the fact that there is a clear theft vulnerabi=
lity<br>
> is something I would say should be considered a "security limitat=
ion".<br>
> <br>
<br>
> As you mentioned, this is of course also a security limitation of a ho=
t<br>
> wallet, so this setup definitely has a lot of advantages over a simple=
hot<br>
> wallet. However, if you compare it against a multisig wallet (eg 2 of =
3),<br>
> you can see that while theft of a single key would never result in any=
<br>
> theft in that setup, it could in a CTV vault. The other trade offs the=
re<br>
> are ones of practicality and convenience.<br>
> <br>
<br>
> This isn't to say a CTV vault wouldn't be useful. Just that it=
has<br>
> significant trade offs.<br>
> <br>
<br>
> @Russel<br>
> <br>
<br>
> > the original MES vault .. commits to the destination address duri=
ng<br>
> <br>
<br>
> unvaulting<br>
> <br>
<br>
> I see. Looking at the MES16 paper, OP_COV isn't described clearly =
enough<br>
> for me to understand that it does that. However, I can imagine how it<=
br>
> might do that.<br>
> <br>
<br>
> One possibility is that the intended destination is predetermined and<=
br>
> hardcoded. This wouldn't be very useful, and also wouldn't be =
different<br>
> than how CTV could do it, so I assume that isn't what you envision=
ed this<br>
> doing.<br>
> <br>
<br>
> I can imagine instead that the definition of the pattern could be spec=
ified<br>
> as a number indicating the number of stack items in the pattern, follo=
wed<br>
> by that number of stack items. If that's how it is done, I can see=
the user<br>
> inputting an intended destination script (corresponding to the intende=
d<br>
> destination address) which would then be somehow rotated in to the rig=
ht<br>
> spot within the pattern, allowing the pattern to specify the coins<br>
> eventually reaching an address with that script. However, this could b=
e<br>
> quite cumbersome, and would require fully specifying the scripts along=
the<br>
> covenant pathways leading to a fair amount of information duplication<=
br>
> (since scripts must be specified both in the covenant and in spending =
the<br>
> subsequent output). Both of these things would seem to make OP_COV in<=
br>
> practice quite an expensive opcode to spend with. It also means that, =
since<br>
> the transactor must fully specify the script, its not possible to take=
<br>
> advantage of taproot's script hiding capabilities (were it to send=
to a<br>
> taproot address).<br>
> <br>
<br>
> However, my assumptions might be incorrect. If you think OP_COV would =
be a<br>
> useful opcode, I would encourage you to write up a complete specificat=
ion.<br>
> <br>
<br>
> > What ways can we build a secured vault that commits to the destin=
ation<br>
> <br>
<br>
> address?<br>
> <br>
<br>
> Some kind of passed-through state allows doing this. With OP_COV (if m=
y<br>
> assumptions above are correct), the intended destination can be passed=
<br>
> through the output script pattern(s). With my own proposed<br>
> op_pushoutputstack<br>
> <a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults=
/blob/main/pos/bip-pushoutputstack.md" rel=3D"noreferrer" target=3D"_blank"=
>https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/=
bip-pushoutputstack.md</a>,<br>
> <br>
<br>
> state is passed as an attachment on the output more directly. Curious =
what<br>
> you think about that proposal.<br>
> <br>
<br>
> > Are there elegant ways of building secure vaults by using CTV plu=
s<br>
> <br>
<br>
> something else.<br>
> <br>
<br>
> Since CTV predefines all the transactions that can happen under its<br=
>
> control, passed state like this can't help because any dynamic sta=
te would<br>
> change the template and render the CTV transaction invalid. I don'=
t see any<br>
> way of solving this problem for CTV.<br>
> <br>
<br>
> I'm curious how you think op_cat could enable this with CTV (other=
than the<br>
> cat+schnorr tricks that don't require CTV at all).<br>
> <br>
<br>
> <br>
<br>
> <br>
<br>
> On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev &=
lt;<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> <br>
<br>
> > Okay, Matt explained to me the intended application of CTV vaults=
off<br>
> > list, so I have a better understanding now.<br>
> > <br>
<br>
> > The CTV vault scheme is designed as an improvement over the tradi=
tional<br>
> > management of hot-wallets and cold-wallets. The CTV vault is logi=
cally on<br>
> > the "cold-side" and lets funds be sent from the "c=
old" side to one's own<br>
> > the hot wallet after the unvaulting delay. In this case, the hot =
wallet<br>
> > funds are always at risk, so it isn't unexpected that those f=
unds could be<br>
> > stolen. After all, that is how hot wallets are today. The advanta=
ge is<br>
> > that funds can be moved from the "cold" side without ne=
eding to dig out the<br>
> > cold keys.<br>
> > <br>
<br>
> > The MES vault scheme applies to a different scenario. In the MES =
case it<br>
> > is the hot funds are inside the vault, and it is the hot key that=
unvaults<br>
> > the funds and sends them to customer's addresses after a dela=
y. If the<br>
> > hot-key is used in any unauthorised way, then funds can be sent t=
o the<br>
> > address of the cold key (the MES vault actually does something fa=
ncy in<br>
> > case of recovery, but it could be adapted to simply send funds to=
a cold<br>
> > wallet).<br>
> > <br>
<br>
> > The MES vault lie somewhere between "better" and "=
different" when compared<br>
> > to the CTV vault. If one is unwilling to use the MES vault on the=
hot side<br>
> > and have every withdrawl vetted, then, while you could use the ME=
S design<br>
> > on the cold side like the CTV vault, it wouldn't really offer=
you any<br>
> > advantages over a CTV vault. However, if you are interested in ma=
naging<br>
> > all your payments through a vault (as I've been imagining) th=
en the CTV<br>
> > vault comes across as ineffective when compared to an MES style v=
ault.<br>
> > <br>
<br>
> > On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <a href=3D"mailto:lf=
-lists@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.com</a><br>
> > wrote:<br>
> > <br>
<br>
> > > Still trying to make sure I understand this concern, let me =
know if I get<br>
> > > this all wrong.<br>
> > > <br>
<br>
> > > On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wr=
ote:<br>
> > > <br>
<br>
> > > > It's not the attackers only choice to succeed. If a=
n attacker steals<br>
> > > > the hot key, then they have<br>
> > > > the option to simply wait for the user to unvault their=
funds of their<br>
> > > > own accord and then race /<br>
> > > > outspend the users transaction with their own. Indeed, =
this is what we<br>
> > > > expect would happen in the<br>
> > > > dark forest.<br>
> > > <br>
<br>
> > > Right, a key security assumption of the CTV-based vaults wou=
ld be that<br>
> > > you MUST NOT EVER withdraw<br>
> > > more in one go than your hot wallet risk tolerance, but give=
n that your<br>
> > > attack isn't any worse than<br>
> > > simply stealing the hot wallet key immediately after a withd=
raw.<br>
> > > <br>
<br>
> > > It does have the drawback that if you ever get a hot wallet =
key stole you<br>
> > > have to rotate all of your<br>
> > > CTV outputs and your CTV outputs must never be any larger th=
an your hot<br>
> > > wallet risk tolerance<br>
> > > amount, both of which are somewhat frustrating limitations, =
but not<br>
> > > security limitations, only<br>
> > > practical ones.<br>
> > > <br>
<br>
> > > > And that's not even mentioning the issues already n=
oted by the document<br>
> > > > regarding fee management,<br>
> > > > which would likely also benefit from a less constrained=
design for<br>
> > > > covenants.<br>
> > > <br>
<br>
> > > Of course I've always been in favor of a less constraine=
d covenants<br>
> > > design from day one for ten<br>
> > > reasons, but that's a whole other rabbit hole :)<br>
> > <br>
<br>
> > _______________________________________________<br>
> > bitcoin-dev mailing list<br>
> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000007a69405dd994c71--
|