path: root/c6/eeb23f1b779f915f22d84bbe68a09e7e62381b

Return-Path: <james.obeirne@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C8894C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Mar 2022 19:46:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id A772440990
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Mar 2022 19:46:18 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CiHs2BRhHhp3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Mar 2022 19:46:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com
 [IPv6:2607:f8b0:4864:20::d35])
 by smtp2.osuosl.org (Postfix) with ESMTPS id D8915404F6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Mar 2022 19:46:16 +0000 (UTC)
Received: by mail-io1-xd35.google.com with SMTP id e22so249330ioe.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 08 Mar 2022 11:46:16 -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=Bkbz1zqQva00XrniLh+IwIEwTOJH9adVw3kVDN8uz/E=;
 b=TN4i+o8VWugVCaeV7V28pMbAGR+kGasac7yer8hobZ9f451V9xN/eQ8HOu9oRPmpso
 mgi1900DePZctpX+9ZlF70vat5TFIGfSw2NIGKeN0mtcBh5ngG+uuRVCecEfmBwNqZsb
 fqpBzLyRjSR5HlsjigznPspTJkjNC2Yqwcc5wFciFqc14PbfpekDt/uW9v4UFPpMyfUr
 /6M732TElzNk5G5o46Pzgx2Cr3hPQG1XVJCcJrWFgw/93TkP8d5IPlvWWwNEatkzrQS8
 jGNUcG1Ti7vI/DAm07Ll3yWx6VzQ8Itx9MRnejkz0iFB8rCeYLRGKTeX0s7T3hUZL2Fi
 0KBw==
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=Bkbz1zqQva00XrniLh+IwIEwTOJH9adVw3kVDN8uz/E=;
 b=Lws1mZXn/n3armQ575wTcpZA8RzkIpbs29JORkuOstwpDBbDuQqDuLlJ3+adqG2V98
 1DNuAjXqF+ke7GPAJ1qaZALFP4RQmc6qZCsA35UIT/CYHslcPXxrg+L9QON21/KVnVtx
 nkoN2SYetLAPmObpa9hZ7q/kOaBx3klG3agCdyQXmuODbJEail3rUFkAaFUgTaaE2nD+
 CfnW6WnJ9T1aGzQwryD5lgtfB0hW2EeEwg0tJEqWRsyvqVlnsPrRiciOgOgjAzXOm8fh
 hUCqHujnW4f5SdTeinEobSfTt5vsgZL6aknX4nzzLWpr0zYjXAffNYD/bXgahqWUwDzV
 p8tQ==
X-Gm-Message-State: AOAM533jyGAh6fncncH0xYHHTxiOYxgCZvoM+et3KPrkLGICOZJ1A6Yx
 YEXfWlnmqxlfRgT+hNks1HiPm+pyEOzlXEmtGTRZZEba6fY=
X-Google-Smtp-Source: ABdhPJzBLYjkEKt4gVQo8jwncf0rRkCyFsAGe0nKyoNU/ZQpuBSZyuVttvcJGLYRBV/aU9JBX3WwbKYL/+ch59NQjwg=
X-Received: by 2002:a05:6638:218e:b0:314:80f4:b31c with SMTP id
 s14-20020a056638218e00b0031480f4b31cmr17018280jaj.85.1646768775702; Tue, 08
 Mar 2022 11:46:15 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfK4PckDdKG4aLASF4p-E8L8YyAbD8M3S_Zwk=wOuA0vfA@mail.gmail.com>
 <CALZpt+FQWWeVuJzye3oPeX+5myRpsT9BwGU8s=PeFcr-pn2ZTQ@mail.gmail.com>
In-Reply-To: <CALZpt+FQWWeVuJzye3oPeX+5myRpsT9BwGU8s=PeFcr-pn2ZTQ@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Tue, 8 Mar 2022 14:46:03 -0500
Message-ID: <CAPfvXfJdZd_1Y_wVB+5kDZz0u==cPGYjdTwV5wgm15Uu_0+wGA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e72c1005d9ba3b8f"
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: Tue, 08 Mar 2022 19:46:18 -0000

--000000000000e72c1005d9ba3b8f
Content-Type: text/plain; charset="UTF-8"

Hey Antoine,

Thanks for taking a look at the repo.

> I believe it's reasonable to expect bugs to slip in affecting the
> output amount or relative-timelock setting correctness

I don't really see the vaults case as any different from other
sufficiently involved uses of bitcoin script - I don't remember anyone
raising these concerns for lightning scripts or DLCs or tapscript use,
any of which could be catastrophic if wallet implementations are not
tested properly.

By comparison, decreasing amount per vault step and one CSV use
seems pretty simple. It's certainly easy to test (as the repo shows),
and really the only parameter the user has is how many blocks to delay
to the `tohot_tx` and perhaps fee-rate. Not too hard to test
comprehensively as far as I can tell.


> 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.

Isn't this kind of inherent to the idea of covenants? You're
precommitting to a spend path. You can put in as many "escape-hatch"
conditions as you want (e.g. Jeremy makes the good point I should
include an immediate-to-cold step that is sibling to the unvaulting),
but fundamentally if you're doing covenants, you're precommitting to a
flow of funds. Otherwise what's the point?


> 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.

Who's saying to trust hardware? Your cold key in the vault structure
could have been generated by performing SHA rounds with the
pebbles in your neighbor's zen garden.

Keeping an actively used multi-sig setup secure certainly isn't free or
easy. Multi-sig ceremonies (which of course can be used in this scheme)
can be cumbersome to coordinate.

If there's a known scheme that doesn't require covenants, but has
similar usage and security characteristics, I'd love
to know it! But being able to lock coins up for an arbitrary amount of
time and then have advance notice of an attempted spend only seems
possible with some kind of covenant technique.

> That said, I think this security advantage is only relevant in the
> context of recursive design, where the partial unvault sends back the
> remaining funds to vault UTXO (not the design proposed here).

I'm not really sure why this would be. Yeah, it would be cool to be able
to partially unvault arbitrary amounts or something, but that seems like
another order of complexity. Personally, I'd be happy to "tranche up"
funds I'd like to store into a collection of single-hop vaults vs.
the techniques available to us today.


> 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 key compromise might not be efficiently detected.

Sure; if you're using vaults I think it's safe to assume you're a fairly
sophisticated user of bitcoin, so running a process that monitors the
chain and responds immediately with keyless to-cold broadcasts
doesn't seem totally out of the question, especially with conservative
block delays.

Pretty straightforward to send such a process (whether it's a program or
a collection of humans) an authenticated signal that says "hey, expect a
withdrawal." This kind of alert allows for cross-referencing the
activity and seems a lot better than nothing!

> 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 the critical data persistence requirement, just reduce the
> surface.

With any use of bitcoin you're going to have critical data that needs to
be maintained (your privkeys at a minimum), so the game is always
reducing surface area. If the presigned-txn vault design
appealed to you as a user, this seems like a strict improvement.

> 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.

I'm not sure who's proposing that counterparties who don't trust each
other make a vault together. I'm thinking of individual users and
custodians, each of which functions as a single trusted entity.

Perhaps your point here is that if I'm a custodian operating a vault and
someone unexpectedly hacks the fee keys that encumber all of my anchor
outputs, they can possibly pin my attempted response to the unvault
transaction - and that's true. But that doesn't seem like a fault unique
to this scheme, and points to the need for better fee-bumping needs a la
SIGHASH_GROUP or transaction sponsors.[0]

> I would say space efficiency is of secondary concern

If every major custodian ends up implementing some type of vault scheme
(not out of the question), this might be a lot of space! However I'm all
for facilitating the flow of bitcoin from major custodians to miners...
but it seems like we could do that more cleanly with a block size
reduction ;). (JUST KIDDING!)

---

I think your idea about having watchtowers serve double-duty for
lightning channels and vault schemes like this is a very good one!


James


[0]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html

--000000000000e72c1005d9ba3b8f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Antoine,<br><br>Thanks for taking a look at the repo.<=
br><br>&gt; I believe it&#39;s reasonable to expect bugs to slip in affecti=
ng the<br>&gt; output amount or relative-timelock setting correctness<br><b=
r>I don&#39;t really see the vaults case as any different from other<br>suf=
ficiently involved uses of bitcoin script - I don&#39;t remember anyone<br>=
raising these concerns for lightning scripts or DLCs or tapscript use,<br>a=
ny of which could be catastrophic if wallet implementations are not<br>test=
ed properly.<br><br>By comparison, decreasing amount per vault step and one=
 CSV use<br>seems pretty simple. It&#39;s certainly easy to test (as the re=
po shows),<br>and really the only parameter the user has is how many blocks=
 to delay<br>to the `tohot_tx` and perhaps fee-rate. Not too hard to test<b=
r>comprehensively as far as I can tell.<br><br><br>&gt; I think the main co=
ncern I have with any hashchain-based vault design<br>&gt; is the immutabil=
ity of the flow paths once the funds are locked to the<br>&gt; root vault U=
TXO.<br><br>Isn&#39;t this kind of inherent to the idea of covenants? You&#=
39;re<br>precommitting to a spend path. You can put in as many &quot;escape=
-hatch&quot;<br>conditions as you want (e.g. Jeremy makes the good point I =
should<br>include an immediate-to-cold step that is sibling to the unvaulti=
ng),<br>but fundamentally if you&#39;re doing covenants, you&#39;re precomm=
itting to a<br>flow of funds. Otherwise what&#39;s the point?<br><br><br>&g=
t; I think the remaining presence of trusted hardware in the vault design<b=
r>&gt; might lead one to ask what&#39;s the security advantage of vaults co=
mpared<br>&gt; to classic multisig setup. <br><br>Who&#39;s saying to trust=
 hardware? Your cold key in the vault structure<br>could have been generate=
d by performing SHA rounds with the<br>pebbles in your neighbor&#39;s zen g=
arden. <br><br>Keeping an actively used multi-sig setup secure certainly is=
n&#39;t free or<br>easy. Multi-sig ceremonies (which of course can be used =
in this scheme)<br>can be cumbersome to coordinate.<br><br><div>If there&#3=
9;s a known scheme that doesn&#39;t require covenants, but has<br></div><di=
v>similar usage and security characteristics, I&#39;d love</div>to know it!=
 But being able to lock coins up for an arbitrary amount of<br>time and the=
n have advance notice of an attempted spend only seems<br>possible with som=
e kind of covenant technique.<br><br>&gt; That said, I think this security =
advantage is only relevant in the<br>&gt; context of recursive design, wher=
e the partial unvault sends back the<br>&gt; remaining funds to vault UTXO =
(not the design proposed here).<br><br>I&#39;m not really sure why this wou=
ld be. Yeah, it would be cool to be able<br>to partially unvault arbitrary =
amounts or something, but that seems like<br>another order of complexity. P=
ersonally, I&#39;d be happy to &quot;tranche up&quot;<br><div>funds I&#39;d=
 like to store into a collection of single-hop vaults vs. <br></div><div>th=
e techniques available to us today.<br></div><br><br>&gt; I think you might=
 need to introduce an intermediary, out-of-chain<br>&gt; protocol step wher=
e the unvault broadcast is formally authorized by<br>&gt; the vault stakeho=
lders. Otherwise it&#39;s hard to qualify &quot;unexpected&quot;,<br>&gt; a=
s hot key compromise might not be efficiently detected.<br><br>Sure; if you=
&#39;re using vaults I think it&#39;s safe to assume you&#39;re a fairly<br=
>sophisticated user of bitcoin, so running a process that monitors the<br>c=
hain and responds immediately with keyless to-cold broadcasts<br>doesn&#39;=
t seem totally out of the question, especially with conservative<br>block d=
elays. <br><br>Pretty straightforward to send such a process (whether it&#3=
9;s a program or<br>a collection of humans) an authenticated signal that sa=
ys &quot;hey, expect a<br>withdrawal.&quot; This kind of alert allows for c=
ross-referencing the<br>activity and seems a lot better than nothing!<br><b=
r>&gt; Don&#39;t you also need the endpoint scriptPubkeys (&lt;cold_pubkey&=
gt;,<br>&gt; &lt;hot_pubkey&gt;), the amounts and CSV value ? Though I thin=
k you can<br>&gt; grind amounts and CSV value in case of loss...But I&#39;m=
 not sure if you<br>&gt; remove the critical data persistence requirement, =
just reduce the<br>&gt; surface.<br><br>With any use of bitcoin you&#39;re =
going to have critical data that needs to<br>be maintained (your privkeys a=
t a minimum), so the game is always<br>reducing surface area. If the presig=
ned-txn vault design<br>appealed to you as a user, this seems like a strict=
 improvement.<br><br>&gt; I&#39;m not sure if the usage of anchor output is=
 safe for any vault<br>&gt; deployment where the funds stakeholders do not =
trust each other or<br>&gt; where the watchtowers are not trusted.<br><br>I=
&#39;m not sure who&#39;s proposing that counterparties who don&#39;t trust=
 each<br>other make a vault together. I&#39;m thinking of individual users =
and<br>custodians, each of which functions as a single trusted entity.<br><=
br>Perhaps your point here is that if I&#39;m a custodian operating a vault=
 and<br>someone unexpectedly hacks the fee keys that encumber all of my anc=
hor<br>outputs, they can possibly pin my attempted response to the unvault<=
br>transaction - and that&#39;s true. But that doesn&#39;t seem like a faul=
t unique<br>to this scheme, and points to the need for better fee-bumping n=
eeds a la<br>SIGHASH_GROUP or transaction sponsors.[0]<br><br>&gt; I would =
say space efficiency is of secondary concern<br><br>If every major custodia=
n ends up implementing some type of vault scheme<br>(not out of the questio=
n), this might be a lot of space! However I&#39;m all<br>for facilitating t=
he flow of bitcoin from major custodians to miners...<br>but it seems like =
we could do that more cleanly with a block size<br>reduction ;). (JUST KIDD=
ING!)<br><br>---<br><br>I think your idea about having watchtowers serve do=
uble-duty for<br>lightning channels and vault schemes like this is a very g=
ood one!<br><br><br>James<br><br><br>[0]:<br><a href=3D"https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-February/019879.html">https://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html</a><=
br></div>

--000000000000e72c1005d9ba3b8f--