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
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 410D1C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2022 21:12:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 27A8760B4C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2022 21:12:59 +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: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Iw4Y7lpbaQuO
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2022 21:12:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
[IPv6:2607:f8b0:4864:20::b2d])
by smtp3.osuosl.org (Postfix) with ESMTPS id 7D1AE60AD8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2022 21:12:57 +0000 (UTC)
Received: by mail-yb1-xb2d.google.com with SMTP id g26so13364081ybj.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Mar 2022 13:12:57 -0800 (PST)
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
:cc; bh=K4w2xqYsKbU+cGx5zsGkbspZGHPAIrI8jLTp92TgEy0=;
b=jjoOBdi2RIvOB/vRnsVR+08ZU6mp/Jte6kjLnWMDy36PntmfghQB7PUUSeA3S9B2Jc
+JFMUn4z+ikMqMlZ2QA5XfJt6QVnuyUtB7XgZW0czmMmB60PLpB4kyjOB3+gc8IUuGOm
C3HtQonnkWTI+WelTPGNgA1QjCEOsjytHQ0vmBaF2cTyLEQoWHlfr92OK+voZUzF9qj3
sSskHNvBrVQRDW58bjzsLEtPj0eo6RMexgjQMidMUEohvaZ/lF7U7/ffd+B+PeMZPvjQ
gcjkSAsQ/T3cUF59yNxXMvlCmwZZ8v/VI01XtSJKwQQyufMZSiUSzogrBQeYaEgwnoI/
YDqw==
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:cc;
bh=K4w2xqYsKbU+cGx5zsGkbspZGHPAIrI8jLTp92TgEy0=;
b=l3e/TPD75+lN3cVvFJE3ZFMbMqLFjmKdMbCNNM315zgIW48VGaRmggPHh5na2EK7sx
WC9t8LngC/ay7V3BVD6anQaS/YcnlR96NvpPZwRlxAg+M4s6mGSnU5jKJH9WNTEGDotI
yOtmUClfQIxHTN3EP2MqRMJWe0NKu2eCBd7ZWyVyj04jNz5+pvuguQ2fZL4MLAKI4Af/
7Q6A8Ro8qcS83y/zLqBbp2PKRUzrDl7qs/ccCdUXmNtATK0+oV6/uLDtEYtNSnyLWI5L
dc0y7nHj/Dam/y++jeHDe98P5B6kgDbPT0ZBKrOecuYf/Ji8s/U6DQtQmZQwEy3f63lA
lpXQ==
X-Gm-Message-State: AOAM531j9Xg/qCuzlDIoi90xfV7PLkyxPx5CgnsJ6DU6GZDaHLrz85qT
/+XLiVpm4nah0ynaOCtSkxiaVw9dhCpzVcLukS4=
X-Google-Smtp-Source: ABdhPJx+XMQiWsiQji4pQv6dzawgjWIYG8tlR9WYDEyZtbXzKbM987pujNnCJ4jpjBStzolFo7Rj0T8ffo6BpN/AyrY=
X-Received: by 2002:a25:4183:0:b0:628:83bd:3a1a with SMTP id
o125-20020a254183000000b0062883bd3a1amr5728185yba.173.1646946776292; Thu, 10
Mar 2022 13:12:56 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfK4PckDdKG4aLASF4p-E8L8YyAbD8M3S_Zwk=wOuA0vfA@mail.gmail.com>
<CALZpt+FQWWeVuJzye3oPeX+5myRpsT9BwGU8s=PeFcr-pn2ZTQ@mail.gmail.com>
<WC-djV9Bhn2JE3cIjjp432LVwg0OBI3z4AZVxxLuplrNisfXMfIM48SnTKOTzzUYpz_KnJ04Q6OnG3_5lxXp4MqqYA1MJux4JnQ1jlpif_4=@protonmail.com>
In-Reply-To: <WC-djV9Bhn2JE3cIjjp432LVwg0OBI3z4AZVxxLuplrNisfXMfIM48SnTKOTzzUYpz_KnJ04Q6OnG3_5lxXp4MqqYA1MJux4JnQ1jlpif_4=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 10 Mar 2022 16:12:44 -0500
Message-ID: <CALZpt+HowiC=32-snDgq0BN1VoPUNXZMLkSgXSDVMQxXhrKATg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000090a1a405d9e3adf6"
X-Mailman-Approved-At: Thu, 10 Mar 2022 21:58:09 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV vaults in the wild
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, 10 Mar 2022 21:12:59 -0000
--00000000000090a1a405d9e3adf6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Zeeman,
> Have not looked at the actual vault design, but I observe that Taproot
allows for a master key (which can be an n-of-n, or a k-of-n with setup
(either expensive or trusted, but I repeat myself)) to back out of any
contract.
>
> This master key could be an "even colder" key that you bury in the desert
to be guarded over by generations of Fremen riding giant sandworms until
the Bitcoin Path prophesied by the Kwisatz Haderach, Satoshi Nakamoto,
arrives.
Yes I agree you can always bless your hashchain-based off-chain contract
with an upgrade path thanks to Taproot. Though now this master key become
the point-of-failure to compromise, compared to hashchain.
I think you can even go fancier than a human desert to hide a master key
with "vaults" geostationary satellites [0] !
[0] https://github.com/oleganza/bitcoin-papers/blob/master/SatelliteVault.m=
d
> Thought: It would be nice if Alice could use Lightning watchtowers as
well, that would help increase the anonymity set of both LN watchtower
users and vault users.
Well, I'm not sure if it's really binding toward the watchtowers.
A LN channel is likely to have a high-frequency of updates (in both
LN-penalty/Eltoo design I think)
A vault is likely to have low-frequency of updates (e.g an once a day
spending)
I think that point is addressable by generating noise traffic from the
vault entity to adopt a classic LN channel pattern. However, as a vault
"high-stake" user, you might not be eager to leak your watchtower IP
address or even Tor onion service to "low-stake" LN channel swarms of
users. So it might end up on different tower deployments because off-chain
contracts' level of safety requirements are not the same, I don't know..
> With Taproot trees the versions of the cold transaction are also stored
off-chain, and each tower gets its own transaction revealing only one of
the tapleaf branches.
> It does have the disadvantage that you have O(log N) x 32 Merkle tree
path references, whereas a presigned Taproot transaction just needs a
single 64-byte signature for possibly millions of towers.
I agree here though note vaults users might be interested to pay the fee
witness premium just to get the tower accountability feature.
Antoine
Le lun. 7 mars 2022 =C3=A0 19:57, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=
=A9crit :
> Good morning Antoine,
>
> > Hi James,
> >
> > Interesting to see a sketch of a CTV-based vault design !
> >
> > I think the main concern I have with any hashchain-based vault design i=
s
> the immutability of the flow paths once the funds are locked to the root
> vault UTXO. By immutability, I mean there is no way to modify the
> unvault_tx/tocold_tx transactions and therefore recover from transaction
> fields
> > corruption (e.g a unvault_tx output amount superior to the root vault
> UTXO amount) or key endpoints compromise (e.g the cold storage key being
> stolen).
> >
> > Especially corruption, in the early phase of vault toolchain deployment=
,
> I believe it's reasonable to expect bugs to slip in affecting the output
> amount or relative-timelock setting correctness (wrong user config,
> miscomputation from automated vault management, ...) and thus definitivel=
y
> freezing the funds. Given the amounts at stake for which vaults are
> designed, errors are likely to be far more costly than the ones we see in
> the deployment of payment channels.
> >
> > It might be more conservative to leverage a presigned transaction data
> design where every decision point is a multisig. I think this design gets
> you the benefit to correct or adapt if all the multisig participants agre=
e
> on. It should also achieve the same than a key-deletion design, as long a=
s
> all
> > the vault's stakeholders are participating in the multisig, they can
> assert that flow paths are matching their spending policy.
>
> Have not looked at the actual vault design, but I observe that Taproot
> allows for a master key (which can be an n-of-n, or a k-of-n with setup
> (either expensive or trusted, but I repeat myself)) to back out of any
> contract.
>
> This master key could be an "even colder" key that you bury in the desert
> to be guarded over by generations of Fremen riding giant sandworms until
> the Bitcoin Path prophesied by the Kwisatz Haderach, Satoshi Nakamoto,
> arrives.
>
> > Of course, relying on presigned transactions comes with higher
> assumptions on the hardware hosting the flow keys. Though as
> hashchain-based vault design imply "secure" key endpoints (e.g
> <cold_pubkey>), as a vault user you're still encumbered with the issues o=
f
> key management, it doesn't relieve you to find trusted hardware. If you
> want to avoid multiplying devices to trust, I believe flow keys can be
> stored on the same keys guarding the UTXOs, before sending to vault custo=
dy.
> >
> > I think the remaining presence of trusted hardware in the vault design
> might lead one to ask what's the security advantage of vaults compared to
> classic multisig setup. IMO, it's introducing the idea of privileges in t=
he
> coins custody : you set up the flow paths once for all at setup with the
> highest level of privilege and then anytime you do a partial unvault you
> don't need the same level of privilege. Partial unvault authorizations ca=
n
> come with a reduced set of verifications, at lower operational costs. Tha=
t
> said, I think this security advantage is only relevant in the context of
> recursive design, where the partial unvault sends back the remaining fund=
s
> to vault UTXO (not the design proposed here).
> >
> > Few other thoughts on vault design, more minor points.
> >
> > "If Alice is watching the mempool/chain, she will see that the unvault
> transaction has been unexpectedly broadcast,"
> >
> > I think you might need to introduce an intermediary, out-of-chain
> protocol step where the unvault broadcast is formally authorized by the
> vault stakeholders. Otherwise it's hard to qualify "unexpected", as hot k=
ey
> compromise might not be efficiently detected.
>
> Thought: It would be nice if Alice could use Lightning watchtowers as
> well, that would help increase the anonymity set of both LN watchtower
> users and vault users.
>
> > "With <hash> OP_CTV, we can ensure that the vault operation is enforced
> by consensus itself, and the vault transaction data can be generated
> deterministically without additional storage needs."
> >
> > Don't you also need the endpoint scriptPubkeys (<cold_pubkey>,
> <hot_pubkey>), the amounts and CSV value ? Though I think you can grind
> amounts and CSV value in case of loss...But I'm not sure if you remove th=
e
> critical data persistence requirement, just reduce the surface.
> >
> > "Because we want to be able to respond immediately, and not have to dig
> out our cold private keys, we use an additional OP_CTV to encumber the
> "swept" coins for spending by only the cold wallet key."
> >
> > I think a robust vault deployment would imply the presence of a set of
> watchtowers, redundant entities able to broadcast the cold transaction in
> reaction to unexpected unvault. One feature which could be interesting is
> "tower accountability", i.e knowing which tower initiated the broadcast,
> especially if it's a faultive one. One way is to watermark the cold
> transaction (e.g tweak nLocktime to past value). Though I believe with CT=
V
> you would need as much different hashes than towers included in your
> unvault output (can be wrapped in a Taproot tree ofc). With presigned
> transactions, tagged versions of the cold transaction are stored off-chai=
n.
>
> With Taproot trees the versions of the cold transaction are also stored
> off-chain, and each tower gets its own transaction revealing only one of
> the tapleaf branches.
> It does have the disadvantage that you have O(log N) x 32 Merkle tree pat=
h
> references, whereas a presigned Taproot transaction just needs a single
> 64-byte signature for possibly millions of towers.
>
> > "In this implementation, we make use of anchor outputs in order to allo=
w
> mummified unvault transactions to have their feerate adjusted dynamically=
."
> >
> > I'm not sure if the usage of anchor output is safe for any vault
> deployment where the funds stakeholders do not trust each other or where
> the watchtowers are not trusted. If a distrusted party can spend the anch=
or
> output it's easy to block the RBF with a pinning.
>
> I agree.
>
> Regards,
> ZmnSCPxj
>
>
--00000000000090a1a405d9e3adf6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Zeeman,<br><br>> Have not looked at the actual vault=
design, but I observe that Taproot allows for a master key (which can be a=
n n-of-n, or a k-of-n with setup (either expensive or trusted, but I repeat=
myself)) to back out of any contract.<br>> <br>> This master key cou=
ld be an "even colder" key that you bury in the desert to be guar=
ded over by generations of Fremen riding giant sandworms until the Bitcoin =
Path prophesied by the Kwisatz Haderach, Satoshi Nakamoto, arrives.<br><br>=
Yes I agree you can always bless your hashchain-based off-chain contract wi=
th an upgrade path thanks to Taproot. Though now this master key become the=
point-of-failure to compromise, compared to hashchain.<br><br>I think you =
can even go fancier than a human desert to hide a master key with "vau=
lts" geostationary satellites [0] !<br><br>[0] <a href=3D"https://gith=
ub.com/oleganza/bitcoin-papers/blob/master/SatelliteVault.md">https://githu=
b.com/oleganza/bitcoin-papers/blob/master/SatelliteVault.md</a><br><br>>=
Thought: It would be nice if Alice could use Lightning watchtowers as well=
, that would help increase the anonymity set of both LN watchtower users an=
d vault users.<br><br>Well, I'm not sure if it's really binding tow=
ard the watchtowers.<br>A LN channel is likely to have a high-frequency of =
updates (in both LN-penalty/Eltoo design I think)<br>A vault is likely to h=
ave low-frequency of updates (e.g an once a day spending)<br><br>I think th=
at point is addressable by generating noise traffic from the vault entity t=
o adopt a classic LN channel pattern. However, as a vault "high-stake&=
quot; user, you might not be eager to leak your watchtower IP address or ev=
en Tor onion service to "low-stake" LN channel swarms of users. S=
o it might end up on different tower deployments because off-chain contract=
s' level of safety requirements are not the same, I don't know..<br=
><br>> With Taproot trees the versions of the cold transaction are also =
stored off-chain, and each tower gets its own transaction revealing only on=
e of the tapleaf branches.<br>> It does have the disadvantage that you h=
ave O(log N) x 32 Merkle tree path references, whereas a presigned Taproot =
transaction just needs a single 64-byte signature for possibly millions of =
towers.<br><br>I agree here though note vaults users might be interested to=
pay the fee witness premium just to get the tower accountability feature.<=
br><br>Antoine</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">Le=C2=A0lun. 7 mars 2022 =C3=A0=C2=A019:57, ZmnSCPxj <<a=
href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">Good morning Antoine,<br>
<br>
> Hi James,<br>
><br>
> Interesting to see a sketch of a CTV-based vault design !<br>
><br>
> I think the main concern I have with any hashchain-based vault design =
is the immutability of the flow paths once the funds are locked to the root=
vault UTXO. By immutability, I mean there is no way to modify the unvault_=
tx/tocold_tx transactions and therefore recover from transaction fields<br>
> corruption (e.g a unvault_tx output amount superior to the root vault =
UTXO amount) or key endpoints compromise (e.g the cold storage key being st=
olen).<br>
><br>
> Especially corruption, in the early phase of vault toolchain deploymen=
t, I believe it's reasonable to expect bugs to slip in affecting the ou=
tput amount or relative-timelock setting correctness (wrong user config, mi=
scomputation from automated vault management, ...) and thus definitively fr=
eezing the funds. Given the amounts at stake for which vaults are designed,=
errors are likely to be far more costly than the ones we see in the deploy=
ment of payment channels.<br>
><br>
> It might be more conservative to leverage a presigned transaction data=
design where every decision point is a multisig. I think this design gets =
you the benefit to correct or adapt if all the multisig participants agree =
on. It should also achieve the same than a key-deletion design, as long as =
all<br>
> the vault's stakeholders are participating in the multisig, they c=
an assert that flow paths are matching their spending policy.<br>
<br>
Have not looked at the actual vault design, but I observe that Taproot allo=
ws for a master key (which can be an n-of-n, or a k-of-n with setup (either=
expensive or trusted, but I repeat myself)) to back out of any contract.<b=
r>
<br>
This master key could be an "even colder" key that you bury in th=
e desert to be guarded over by generations of Fremen riding giant sandworms=
until the Bitcoin Path prophesied by the Kwisatz Haderach, Satoshi Nakamot=
o, arrives.<br>
<br>
> Of course, relying on presigned transactions comes with higher assumpt=
ions on the hardware hosting the flow keys. Though as hashchain-based vault=
design imply "secure" key endpoints (e.g <cold_pubkey>), a=
s a vault user you're still encumbered with the issues of key managemen=
t, it doesn't relieve you to find trusted hardware. If you want to avoi=
d multiplying devices to trust, I believe flow keys can be stored on the sa=
me keys guarding the UTXOs, before sending to vault custody.<br>
><br>
> I think the remaining presence of trusted hardware in the vault design=
might lead one to ask what's the security advantage of vaults compared=
to classic multisig setup. IMO, it's introducing the idea of privilege=
s in the coins custody : you set up the flow paths once for all at setup wi=
th the highest level of privilege and then anytime you do a partial unvault=
you don't need the same level of privilege. Partial unvault authorizat=
ions can come with a reduced set of verifications, at lower operational cos=
ts. That said, I think this security advantage is only relevant in the cont=
ext of recursive design, where the partial unvault sends back the remaining=
funds to vault UTXO (not the design proposed here).<br>
><br>
> Few other thoughts on vault design, more minor points.<br>
><br>
> "If Alice is watching the mempool/chain, she will see that the un=
vault transaction has been unexpectedly broadcast,"<br>
><br>
> I think you might need to introduce an intermediary, out-of-chain prot=
ocol step where the unvault broadcast is formally authorized by the vault s=
takeholders. Otherwise it's hard to qualify "unexpected", as =
hot key compromise might not be efficiently detected.<br>
<br>
Thought: It would be nice if Alice could use Lightning watchtowers as well,=
that would help increase the anonymity set of both LN watchtower users and=
vault users.<br>
<br>
> "With <hash> OP_CTV, we can ensure that the vault operation=
is enforced by consensus itself, and the vault transaction data can be gen=
erated deterministically without additional storage needs."<br>
><br>
> Don't you also need the endpoint scriptPubkeys (<cold_pubkey>=
;, <hot_pubkey>), the amounts and CSV value ? Though I think you can =
grind amounts and CSV value in case of loss...But I'm not sure if you r=
emove the critical data persistence requirement, just reduce the surface.<b=
r>
><br>
> "Because we want to be able to respond immediately, and not have =
to dig out our cold private keys, we use an additional OP_CTV to encumber t=
he "swept" coins for spending by only the cold wallet key."<=
br>
><br>
> I think a robust vault deployment would imply the presence of a set of=
watchtowers, redundant entities able to broadcast the cold transaction in =
reaction to unexpected unvault. One feature which could be interesting is &=
quot;tower accountability", i.e knowing which tower initiated the broa=
dcast, especially if it's a faultive one. One way is to watermark the c=
old transaction (e.g tweak nLocktime to past value). Though I believe with =
CTV you would need as much different hashes than towers included in your un=
vault output (can be wrapped in a Taproot tree ofc). With presigned transac=
tions, tagged versions of the cold transaction are stored off-chain.<br>
<br>
With Taproot trees the versions of the cold transaction are also stored off=
-chain, and each tower gets its own transaction revealing only one of the t=
apleaf branches.<br>
It does have the disadvantage that you have O(log N) x 32 Merkle tree path =
references, whereas a presigned Taproot transaction just needs a single 64-=
byte signature for possibly millions of towers.<br>
<br>
> "In this implementation, we make use of anchor outputs in order t=
o allow mummified unvault transactions to have their feerate adjusted dynam=
ically."<br>
><br>
> I'm not sure if the usage of anchor output is safe for any vault d=
eployment where the funds stakeholders do not trust each other or where the=
watchtowers are not trusted. If a distrusted party can spend the anchor ou=
tput it's easy to block the RBF with a pinning.<br>
<br>
I agree.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div>
--00000000000090a1a405d9e3adf6--
|