path: root/67/5c7771e22de7e1120d76282a0c09b5d9a633f9

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 35B67C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 22:31:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 24AF361287
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 22:31:47 +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 e_j0imdCrH20
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 22:31:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com
 [IPv6:2607:f8b0:4864:20::b2f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 0C7E161281
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 22:31:44 +0000 (UTC)
Received: by mail-yb1-xb2f.google.com with SMTP id j2so13876753ybu.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 14:31:44 -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=WTJSrzCBePQfCKK7fBzUs1hcwrkT2Yf92ufOcdn8oXw=;
 b=COCLnX/HjkXhsHJ/T/x38DP4rNHmfSb30VTBMsVNxz5SceWKPw0lcp9iDKEZOlL6yY
 L84Qwc6vFZmLOS9Py0ops1FD/6ChaqAeI7lRcX9tbl6u/w6NP827NjWLWwAYrBpKEIHL
 kfpPIZ98qrHy75XF3EKrvL+Se4ofADl2yAbSUR0O98KcK9Zw7Lv3yoHJRMgpwOaOrp9Y
 vefrI1jLbaEuAhaDQHqeLTqBgzt8BS9Dd+2XB72wfyvJ4+sW4gRNZAQq6j45CdakSAhr
 iYYMvqx2s56jsx//5AtHxC2dVD5GhrhY8zsMsyhKj23sHe3KzIF3UyuzTQMjf/XHUjiw
 kz6Q==
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=WTJSrzCBePQfCKK7fBzUs1hcwrkT2Yf92ufOcdn8oXw=;
 b=1JU+BhJUeH4A6GXRRNOVP01xuci3NaYsp/AtWqMFMVJO7rS+w/6TQnQydPP0PKUmhg
 M1sXllaPqVLSWF0Av6kaofB0byr49L34ZtxMghR7lpcP5YrmgKGqMfUwzYF+aiVf9ePP
 Nf+vz6+GtWT38bhU9zec7Pach4PSoiEpucj710vc0FvcNBsWpOLw0bMZDY+Srp2ls91J
 N8HdVoEaX+dehIc5KIQ+faJ3qx9asQRkVCXnvlZPRR3/Yq0NnauNHRbM6jX16ZnfDn4w
 0V+jyoGrElWDkcpLW8r9Xo6L/mejsA3IHE8VM0XMoVZ2SuoMCGpt4CVaXUPH5od0QJHY
 p/VA==
X-Gm-Message-State: AOAM531ppPf9sOOzr0wWyBtvENwTq+dIm7Fvu9FzWon4KxovwFAGPLH3
 2yhnBm78280+wp5Xc4Pu1KoILSMSANSjbh8dwqtnW0qN0sA=
X-Google-Smtp-Source: ABdhPJw4BQnn4O4G5mH733U2HrfzdbPmrRebmYLG3/2DGnCBxg2PiUVQNHmQaQzv3OOu1W8Uw35zxyXA6MrdGqcyn9Y=
X-Received: by 2002:a5b:f87:0:b0:62b:f9d8:ed5 with SMTP id
 q7-20020a5b0f87000000b0062bf9d80ed5mr5952614ybh.467.1646951503829; 
 Thu, 10 Mar 2022 14:31:43 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfK4PckDdKG4aLASF4p-E8L8YyAbD8M3S_Zwk=wOuA0vfA@mail.gmail.com>
 <CALZpt+FQWWeVuJzye3oPeX+5myRpsT9BwGU8s=PeFcr-pn2ZTQ@mail.gmail.com>
 <CAPfvXfJdZd_1Y_wVB+5kDZz0u==cPGYjdTwV5wgm15Uu_0+wGA@mail.gmail.com>
In-Reply-To: <CAPfvXfJdZd_1Y_wVB+5kDZz0u==cPGYjdTwV5wgm15Uu_0+wGA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 10 Mar 2022 17:31:32 -0500
Message-ID: <CALZpt+H9LWoZGHu_VzcVoxHra6WGGoB+ogE-nmeMmHZ4Bb7cCA@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000591d3f05d9e4c7f7"
X-Mailman-Approved-At: Thu, 10 Mar 2022 22:39:08 +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 22:31:47 -0000

--000000000000591d3f05d9e4c7f7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi James,

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

I think on the lightning side there were enough concerns w.r.t bugs
affecting the toolchains in their infancy phases to motivate developers to
bound max channel value to 2^24 for a while [0]

[0] https://github.com/lightning/bolts/pull/590

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

As of today you won't be able to test against bitcoin core that a CSV'ed
transaction is valid for propagation across the network because your
mempool is going to reject it as non-final [1]

[1] https://github.com/bitcoin/bitcoin/pull/21413

Verifying that your whole set of off-chain covenanted transactions is
propagating well at different feerate levels, and there is no surface
offered to a malicious vault co-owner to pin them can turn quickly as a
real challenge, I believe.

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

Yeah, I agree here that's the idea of covenants to commit to a flow of
funds. However, I think leveraging hashchain covenants in terms of  vault
design comes at the price to make transaction generation errors or key
endpoint compromises hardly irrevocable.

I would say you can achieve the same end goal of precommiting to a flow of
funds with "pre-signed" transactions (and actually that's what we do for
lightning) though while still keeping the upgrade emergency option open. Of
course, you re-introduce more assumptions on the devices where the upgrade
keys are laying.

I believe both designs are viable, it's more a matter of explaining
security and reliability trade-offs to the vaults users. They might be even
complimentary as answering different classes of self-custody needs. I'm
just worried as protocol devs, we have a good understanding of those
trade-offs to convey them well to the vaults users and have them make a
well-informed decision.

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

Well, if by covenants you include pre-signed transactions vaults designs,
no sadly I don't know schemes offering the same usage and security
characteristics...

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

Hmmm if you would like to be able to partially unvault arbitrary amounts,
while still precommitting to the flow of funds, you might need a sighash
flag extension like SIGHASH_ANYAMOUNT ? (my 2 sats, I don't have a design)

Yes, "tranche up" funds where the remainder is sent back to a vault UTXO
sounds to me belonging to the recursive class of design, and yeah I agree
that might be one of the most interesting features of vaults.

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

Yep, a nice improvement. And now you enter into a new wormhole of providing
your process with keys to authenticate the signals and how those
non-necessarily bitcoin locking-UTXO keys can be compromised or even how
the alert mechanism can be abused. We know, security is a never over game :=
D

> 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 agree here, the critical data surface sounds to be better with
hashchain-based vaults designs.

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

If you have a set of custodians, even if they belong to the same
administrative entity, one of them might be compromised or bribed and leak
the anchor output key to an attacker, therefore preventing the remaining
custodians from using the `tocold_tx` ability as expected.

I'm not sure if thinking of the custodians as a single trusted entity is a
hard enough assumption for high-stake vaults designs..

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

Yes agree here.

> 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!)

Haha, designing _inefficient_ off-chain contracts for high buying power
users to have them pay better the miners in a post-block subsidy world.
Sounds smart, well done :)

Antoine

Le mar. 8 mars 2022 =C3=A0 14:46, James O'Beirne <james.obeirne@gmail.com> =
a
=C3=A9crit :

> 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/019=
879.html
>

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

<div dir=3D"ltr">Hi James,<br><br>&gt; I don&#39;t really see the vaults ca=
se as any different from other<br>&gt; sufficiently involved uses of bitcoi=
n script - I don&#39;t remember anyone<br>&gt; raising these concerns for l=
ightning scripts or DLCs or tapscript use,<br>&gt; any of which could be ca=
tastrophic if wallet implementations are not<br>&gt; tested properly.<br><b=
r>I think on the lightning side there were enough concerns w.r.t bugs affec=
ting the toolchains in their infancy phases to motivate developers to bound=
 max channel value to 2^24 for a while [0]<br><br>[0] <a href=3D"https://gi=
thub.com/lightning/bolts/pull/590">https://github.com/lightning/bolts/pull/=
590</a><br><br>&gt; By comparison, decreasing amount per vault step and one=
 CSV use<br>&gt; seems pretty simple. It&#39;s certainly easy to test (as t=
he repo shows),<br>&gt; and really the only parameter the user has is how m=
any blocks to delay<br>&gt; to the `tohot_tx` and perhaps fee-rate. Not too=
 hard to test<br>&gt; comprehensively as far as I can tell.<br><br>As of to=
day you won&#39;t be able to test against bitcoin core that a CSV&#39;ed tr=
ansaction is valid for propagation across the network because your mempool =
is going to reject it as non-final [1]<br><br>[1] <a href=3D"https://github=
.com/bitcoin/bitcoin/pull/21413">https://github.com/bitcoin/bitcoin/pull/21=
413</a><br><br>Verifying that your whole set of off-chain covenanted transa=
ctions is propagating well at different feerate levels, and there is no sur=
face offered to a malicious vault co-owner to pin them can turn quickly as =
a real challenge, I believe.<br><br>&gt; I think the main concern I have wi=
th any hashchain-based vault design<br>&gt; is the immutability of the flow=
 paths once the funds are locked to the<br>&gt; root vault UTXO.<br><br>&gt=
; Isn&#39;t this kind of inherent to the idea of covenants? You&#39;re<br>&=
gt; precommitting to a spend path. You can put in as many &quot;escape-hatc=
h&quot;<br>&gt; conditions as you want (e.g. Jeremy makes the good point I =
should<br>&gt; include an immediate-to-cold step that is sibling to the unv=
aulting),<br>&gt; but fundamentally if you&#39;re doing covenants, you&#39;=
re precommitting to a<br>&gt; flow of funds. Otherwise what&#39;s the point=
?<br><br>Yeah, I agree here that&#39;s the idea of covenants to commit to a=
 flow of funds. However, I think leveraging hashchain covenants in terms of=
=C2=A0 vault design comes at the price to make transaction generation error=
s or key endpoint compromises hardly irrevocable.<br><br>I would say you ca=
n achieve the same end goal of precommiting to a flow of funds with &quot;p=
re-signed&quot; transactions (and actually that&#39;s what we do for lightn=
ing) though while still keeping the upgrade emergency option open. Of cours=
e, you re-introduce more assumptions on the devices where the upgrade keys =
are laying.<br><br>I believe both designs are viable, it&#39;s more a matte=
r of explaining security and reliability trade-offs to the vaults users. Th=
ey might be even complimentary as answering different classes of self-custo=
dy needs. I&#39;m<br>just worried as protocol devs, we have a good understa=
nding of those trade-offs to convey them well to the vaults users and have =
them make a well-informed decision.<br><br>&gt; Who&#39;s saying to trust h=
ardware? Your cold key in the vault structure<br>&gt; could have been gener=
ated by performing SHA rounds with the<br>&gt; pebbles in your neighbor&#39=
;s zen garden.<br>&gt; <br>&gt; Keeping an actively used multi-sig setup se=
cure certainly isn&#39;t free or<br>&gt; easy. Multi-sig ceremonies (which =
of course can be used in this scheme)<br>&gt; can be cumbersome to coordina=
te.<br>&gt; <br>&gt; If there&#39;s a known scheme that doesn&#39;t require=
 covenants, but has<br>&gt; similar usage and security characteristics, I&#=
39;d love<br>&gt; to know it! But being able to lock coins up for an arbitr=
ary amount of<br>&gt; time and then have advance notice of an attempted spe=
nd only seems<br>&gt; possible with some kind of covenant technique.<br><br=
>Well, if by covenants you include pre-signed transactions vaults designs, =
no sadly I don&#39;t know schemes offering the same usage and security char=
acteristics...<br><br>&gt; That said, I think this security advantage is on=
ly relevant in the<br>&gt; context of recursive design, where the partial u=
nvault sends back the<br>&gt; remaining funds to vault UTXO (not the design=
 proposed here).<br><br>&gt; I&#39;m not really sure why this would be. Yea=
h, it would be cool to be able<br>&gt; to partially unvault arbitrary amoun=
ts or something, but that seems like<br>&gt; another order of complexity. P=
ersonally, I&#39;d be happy to &quot;tranche up&quot;<br>&gt; funds I&#39;d=
 like to store into a collection of single-hop vaults vs.<br>&gt; the techn=
iques available to us today.<br><br>Hmmm if you would like to be able to pa=
rtially unvault arbitrary amounts, while still precommitting to the flow of=
 funds, you might need a sighash flag extension like SIGHASH_ANYAMOUNT ? (m=
y 2 sats, I don&#39;t have a design)<br><br>Yes, &quot;tranche up&quot; fun=
ds where the remainder is sent back to a vault UTXO sounds to me belonging =
to the recursive class of design, and yeah I agree that might be one of the=
 most interesting features of vaults.<br><br>&gt; Pretty straightforward to=
 send such a process (whether it&#39;s a program or<br>&gt; a collection of=
 humans) an authenticated signal that says &quot;hey, expect a<br>&gt; with=
drawal.&quot; This kind of alert allows for cross-referencing the<br>&gt; a=
ctivity and seems a lot better than nothing!<br><br>Yep, a nice improvement=
. And now you enter into a new wormhole of providing your process with keys=
 to authenticate the signals and how those non-necessarily bitcoin locking-=
UTXO keys can be compromised or even how the alert mechanism can be abused.=
 We know, security is a never over game :D<br><br>&gt; With any use of bitc=
oin you&#39;re going to have critical data that needs to<br>&gt; be maintai=
ned (your privkeys at a minimum), so the game is always<br>&gt; reducing su=
rface area. If the presigned-txn vault design<br>&gt; appealed to you as a =
user, this seems like a strict improvement.<br><br>I agree here, the critic=
al data surface sounds to be better with hashchain-based vaults designs.<br=
><br>&gt; I&#39;m not sure who&#39;s proposing that counterparties who don&=
#39;t trust each<br>&gt; other make a vault together. I&#39;m thinking of i=
ndividual users and<br>&gt; custodians, each of which functions as a single=
 trusted entity.<br><br>If you have a set of custodians, even if they belon=
g to the same administrative entity, one of them might be compromised or br=
ibed and leak the anchor output key to an attacker, therefore preventing th=
e remaining custodians from using the `tocold_tx` ability as expected.<br><=
br>I&#39;m not sure if thinking of the custodians as a single trusted entit=
y is a hard enough assumption for high-stake vaults designs..<br><br>&gt; P=
erhaps your point here is that if I&#39;m a custodian operating a vault and=
<br>&gt; someone unexpectedly hacks the fee keys that encumber all of my an=
chor<br>&gt; outputs, they can possibly pin my attempted response to the un=
vault<br>&gt; transaction - and that&#39;s true. But that doesn&#39;t seem =
like a fault unique<br>&gt; to this scheme, and points to the need for bett=
er fee-bumping needs a la<br>&gt; SIGHASH_GROUP or transaction sponsors.[0]=
<br><br>Yes agree here.<br><br>&gt; I would say space efficiency is of seco=
ndary concern<br><br>&gt; If every major custodian ends up implementing som=
e type of vault scheme<br>&gt; (not out of the question), this might be a l=
ot of space! However I&#39;m all<br>&gt; for facilitating the flow of bitco=
in from major custodians to miners...<br>&gt; but it seems like we could do=
 that more cleanly with a block size<br>&gt; reduction ;). (JUST KIDDING!)<=
br><br>Haha, designing _inefficient_ off-chain contracts for high buying po=
wer users to have them pay better the miners in a post-block subsidy world.=
 Sounds smart, well done :)<br><br>Antoine<br></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 8 mars 2022 =C3=
=A0=C2=A014:46, James O&#39;Beirne &lt;<a href=3D"mailto:james.obeirne@gmai=
l.com">james.obeirne@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hey Antoine,<br=
><br>Thanks for taking a look at the repo.<br><br>&gt; I believe it&#39;s r=
easonable to expect bugs to slip in affecting the<br>&gt; output amount or =
relative-timelock setting correctness<br><br>I don&#39;t really see the vau=
lts case as any different from other<br>sufficiently involved uses of bitco=
in script - I don&#39;t remember anyone<br>raising these concerns for light=
ning scripts or DLCs or tapscript use,<br>any of which could be catastrophi=
c if wallet implementations are not<br>tested properly.<br><br>By compariso=
n, decreasing amount per vault step and one CSV use<br>seems pretty simple.=
 It&#39;s certainly easy to test (as the repo shows),<br>and really the onl=
y parameter the user has is how many blocks to delay<br>to the `tohot_tx` a=
nd perhaps fee-rate. Not too hard to test<br>comprehensively as far as I ca=
n tell.<br><br><br>&gt; I think the main concern I have with any hashchain-=
based vault design<br>&gt; is the immutability of the flow paths once the f=
unds are locked to the<br>&gt; root vault UTXO.<br><br>Isn&#39;t this kind =
of inherent to the idea of covenants? You&#39;re<br>precommitting to a spen=
d path. You can put in as many &quot;escape-hatch&quot;<br>conditions as yo=
u want (e.g. Jeremy makes the good point I should<br>include an immediate-t=
o-cold step that is sibling to the unvaulting),<br>but fundamentally if you=
&#39;re doing covenants, you&#39;re precommitting to a<br>flow of funds. Ot=
herwise what&#39;s the point?<br><br><br>&gt; I think the remaining presenc=
e of trusted hardware in the vault design<br>&gt; might lead one to ask wha=
t&#39;s the security advantage of vaults compared<br>&gt; to classic multis=
ig setup. <br><br>Who&#39;s saying to trust hardware? Your cold key in the =
vault structure<br>could have been generated by performing SHA rounds with =
the<br>pebbles in your neighbor&#39;s zen garden. <br><br>Keeping an active=
ly used multi-sig setup secure certainly isn&#39;t free or<br>easy. Multi-s=
ig ceremonies (which of course can be used in this scheme)<br>can be cumber=
some to coordinate.<br><br><div>If there&#39;s a known scheme that doesn&#3=
9;t require covenants, but has<br></div><div>similar usage and security cha=
racteristics, I&#39;d love</div>to know it! But being able to lock coins up=
 for an arbitrary amount of<br>time and then have advance notice of an atte=
mpted spend only seems<br>possible with some kind of covenant technique.<br=
><br>&gt; That said, I think this security advantage is only relevant in th=
e<br>&gt; context of recursive design, where 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 would be. Yeah, it would be cool to=
 be able<br>to partially unvault arbitrary amounts or something, but that s=
eems like<br>another order of complexity. Personally, 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>the techniques available to us tod=
ay.<br></div><br><br>&gt; I think you might need to introduce an intermedia=
ry, out-of-chain<br>&gt; protocol step where the unvault broadcast is forma=
lly authorized by<br>&gt; the vault stakeholders. Otherwise it&#39;s hard t=
o qualify &quot;unexpected&quot;,<br>&gt; as hot key compromise might not b=
e 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>chain and responds immediately wi=
th keyless to-cold broadcasts<br>doesn&#39;t seem totally out of the questi=
on, especially with conservative<br>block delays. <br><br>Pretty straightfo=
rward to send such a process (whether it&#39;s a program or<br>a collection=
 of humans) an authenticated signal that says &quot;hey, expect a<br>withdr=
awal.&quot; This kind of alert allows for cross-referencing the<br>activity=
 and seems a lot better than nothing!<br><br>&gt; Don&#39;t you also need t=
he endpoint scriptPubkeys (&lt;cold_pubkey&gt;,<br>&gt; &lt;hot_pubkey&gt;)=
, the amounts and CSV value ? Though I think 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 at a minimum), so the game is alw=
ays<br>reducing surface area. If the presigned-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; depl=
oyment where the funds stakeholders do not trust each other or<br>&gt; wher=
e the watchtowers are not trusted.<br><br>I&#39;m not sure who&#39;s propos=
ing that counterparties who don&#39;t trust each<br>other make a vault toge=
ther. 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 th=
at if I&#39;m a custodian operating a vault and<br>someone unexpectedly hac=
ks the fee keys that encumber all of my anchor<br>outputs, they can possibl=
y pin my attempted response to the unvault<br>transaction - and that&#39;s =
true. But that doesn&#39;t seem like a fault unique<br>to this scheme, and =
points to the need for better fee-bumping needs a la<br>SIGHASH_GROUP or tr=
ansaction sponsors.[0]<br><br>&gt; I would say space efficiency is of secon=
dary concern<br><br>If every major custodian ends up implementing some type=
 of vault scheme<br>(not out of the question), this might be a lot of space=
! However I&#39;m all<br>for facilitating the flow of bitcoin from major cu=
stodians to miners...<br>but it seems like we could do that more cleanly wi=
th a block size<br>reduction ;). (JUST KIDDING!)<br><br>---<br><br>I think =
your idea about having watchtowers serve double-duty for<br>lightning chann=
els and vault schemes like this is a very good one!<br><br><br>James<br><br=
><br>[0]:<br><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2022-February/019879.html" target=3D"_blank">https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2022-February/019879.html</a><br></div>
</blockquote></div>

--000000000000591d3f05d9e4c7f7--