'[bitcoin-dev] CTV, covenants and vaults (was: : Re: ANYPREVOUT in place of CTV)'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    [bitcoin-dev] CTV, covenants and vaults (was: : Re:  ANYPREVOUT in place of CTV)
From:       darosior via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date:       2022-04-26 10:20:04
Message-ID: RzE3z11XiwieE88jYt1FX_psUhQLltsoBnGIrs-43qGtjtpLPRzEHWS1VNIZ5lpa3rhj_PjqjhDY5l9doAH-GPGNXPb-hBxDcMrHnF_Z-6c= () protonmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

[Attachment #4 (text/plain)]

> > i doubt CTV is necessary nor sufficient for this

> I would be interested to hear more on this.

A lot of people have been conflating vaults and covenants, especially lately. I \
believe we should differentiate more Bitcoin vaults, a scheme that defines a "staged \
transaction process" [0], and Bitcoin covenants. I find that there was a lot of \
confusion spread around that. Everything was a vault, from the marketing of a mobile \
wallet with a 2of3 account to a covenant scheme. ( :) It led to the confusion that a \
                Bitcoin covenant would be necessary in order to have a Bitcoin vault. \
                It's
incorrect: https://github.com/revault/practical-revault/blob/master/introduction.md \
(or [1], but albeit pretty clever, i don't think it's practical).

Now, CTV is useful for Bitcoin vaults. For instance i believe it's useful to \
pre-commit to a Cancel transaction directly in the Unvault Script. This matters a lot \
as today you need to be sure that your watchtowers (or any other network monitor) \
have had the Cancel transaction signature of all participants in the vault before you \
sign the Unvault transaction. A covenant, as simple as CTV, fixes this. It makes sure \
that not only any Unvault you sign can be Canceled, but also that when you spin up a \
new watchtower you don't need to send to it all the signatures for all the current \
vaults. Of course you'd want to add some secret here to avoid the annoyance of all \
your Unvaults being able to be canceled by some rando on the network. But you can \
derive them from a secret shared only once. Also on the topic of reducing \
interactivity, i think that CTV or another more powerful covenants that allows to \
commit to all parts of a transaction (for malleability) can be useful for the \
complicated issue of fee bumping [2].

However, it's not sufficient. You are not going to be able to receive coins on a CTV \
that commits to the Unvault (whose output would commit to either the Cancel \
immediately, or something else after a delay). It would be an enormous footgun. For \
this, i believe something like TLUV with IN_OUT_AMOUNT [3] is a much more interesting \
direction. Furthermore, committing entirely to the withdrawal amounts in advance is \
very impractical. It is the one largest UX barrier in my opinion. Users don't think \
in coins, but in amount to transfer. In order to have an almost decent UX you would \
have to prepare a first stage transaction that creates a nice (what is nice? It's \
very hard to reason about) distribution of coin amounts. This is a big tradeoff \
between usability and cost (granularity). Of course it's not new to CTV, It's an \
issue today with Revault. It's just a problem faced by today's implementation(s) (i \
don't know of any other "real" vault implementation) of Bitcoin vaults that CTV does \
not solve. I realise that you might not care to receive coins on a single-sig Script \
and have a vaulting step in a single-party situation. I guess i just think vaults are \
more interesting in organisational situations, where a set of participants only \
marginally trust another one (that may be a subset) and want to both limit the amount \
they have access to and apply policies on how they would use the funds.

Antoine

[0] All vaults architectures i know of are characterized by the necessity to unlock \
the funds in multiple stages, one of which is timelocked.
[1] https://arxiv.org/abs/2005.11776
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html[3] \
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html

------- Original Message -------
Le lundi 25 avril 2022 Ă  6:57 PM, Nadav Ivgi <nadav@shesek.info> a ĂŠcrit :

> darosior via bitcoin-dev wrote:> i doubt CTV is necessary nor sufficient for this
> 
> I would be interested to hear more on this.
> 
> Is it not necessary because you can exchange and store pre-signed transactions \
> instead? 
> What purpose is it not sufficient for? There are some vault designs out there that \
> are able to achieve interesting properties with CTV, like James O'Beirne's \
> simple-ctv-vault: 
> https://github.com/jamesob/simple-ctv-vault
> (the basic design expressed in Minsc: \
> https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4) 
> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev \
> <bitcoin-dev@lists.linuxfoundation.org> wrote: 
> > I would like to know people's sentiment about doing (a very slightly tweaked \
> > version of) BIP118 in place of (or before doing) BIP119.
> > 
> > SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 \
> > years. It presents proven and implemented usecases, that are demanded and (please \
> > someone correct me if i'm wrong) more widely accepted than CTV's.
> > 
> > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional \
> > [0], can emulate CTV just fine. Sure then you can't have bare or Segwit v0 CTV, \
> > and it's a bit more expensive to use. But we can consider CTV an optimization of \
> > APO-AS covenants. 
> > CTV advocates have been presenting vaults as the flagship usecase. Although as \
> > someone who've been trying to implement practical vaults for the past 2 years i \
> > doubt CTV is necessary nor sufficient for this (but still useful!), using APO-AS \
> > covers it. And it's not a couple dozen more virtual bytes that are going to \
> > matter for a potential vault user.
> > 
> > If after some time all of us who are currently dubious about CTV's stated \
> > usecases are proven wrong by onchain usage of a less efficient construction to \
> > achieve the same goal, we could roll-out CTV as an optimization. In the meantime \
> > others will have been able to deploy new applications leveraging ANYPREVOUT \
> > (Eltoo, blind statechains, etc..[1]).
> > 
> > Given the interest in, and demand for, both simple covenants and better offchain \
> > protocols it seems to me that BIP118 is a soft fork candidate that could benefit \
> > more (if not most of) Bitcoin users. Actually i'd also be interested in knowing \
> > if people would oppose the APO-AS part of BIP118, since it enables CTV's \
> > features, for the same reason they'd oppose BIP119. 
> > [0] That is, to not commit to the other inputs of the transaction (via \
> > `sha_sequences` and maybe also `sha_amounts`). Cf \
> > https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message. \
> >  [1] https://anyprevout.xyz/ "Use Cases" section
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Attachment #5 (text/html)]

<div style="font-family: arial; font-size: 14px; color: rgb(34, 34, 34);"><span>&gt; \
&gt; i doubt CTV is necessary nor sufficient for \
this</span><div><br></div><div><span>&gt; I would be interested to hear more on \
this.</span></div><div><br></div><div><span>A lot of people have been conflating \
vaults and covenants, especially lately. I believe we \
should</span></div><div><span>differentiate more Bitcoin vaults, a scheme that \
defines a "staged transaction process" [0], and \
Bitcoin</span></div><div><span>covenants. I find that there was a lot of confusion \
spread around that. Everything was a vault, from the</span></div><div><span>marketing \
of a mobile wallet with a 2of3 account to a covenant scheme. ( \
:)</span></div><div><span>It led to the confusion that a Bitcoin covenant would be \
necessary in order to have a Bitcoin vault. It's</span></div><div><span>incorrect: <a \
target="_blank" rel="noreferrer nofollow noopener" \
href="https://github.com/revault/practical-revault/blob/master/introduction.md">https://github.com/revault/practical-revault/blob/master/introduction.md</a> \
(or [1], but albeit pretty</span></div><div><span>clever, i don't think it's \
practical).</span></div><div><br></div><div><span>Now, CTV is useful for Bitcoin \
vaults. For instance i believe it's useful to pre-commit to a \
Cancel</span></div><div><span>transaction directly in the Unvault Script. This \
matters a lot as today you need to be sure that \
your</span></div><div><span>watchtowers (or any other network monitor) have had the \
Cancel transaction signature of all participants in</span></div><div><span>the vault \
before you sign the Unvault transaction.</span></div><div><span>A covenant, as simple \
as CTV, fixes this. It makes sure that not only any Unvault you sign can be \
Canceled,</span></div><div><span>but also that when you spin up a new watchtower you \
don't need to send to it all the signatures for all \
the</span></div><div><span>current vaults. Of course you'd want to add some secret \
here to avoid the annoyance of all your Unvaults being</span></div><div><span>able to \
be canceled by some rando on the network. But you can derive them from a secret \
shared only once.</span></div><div><span>Also on the topic of reducing interactivity, \
i think that CTV or another more powerful covenants that \
allows</span></div><div><span>to commit to all parts of a transaction (for \
malleability) can be useful for the complicated issue of \
fee</span></div><div><span>bumping \
[2].</span></div><div><br></div><div><span>However, it's not sufficient. You are not \
going to be able to receive coins on a CTV that commits to \
the</span></div><div><span>Unvault (whose output would commit to either the Cancel \
immediately, or something else after a delay). It</span></div><div><span>would be an \
enormous footgun. For this, i believe something like TLUV with IN_OUT_AMOUNT [3] is a \
much more</span></div><div><span>interesting \
direction.</span></div><div><span>Furthermore, committing entirely to the withdrawal \
amounts in advance is very impractical. It is the one</span></div><div><span>largest \
UX barrier in my opinion. Users don't think in coins, but in amount to transfer. In \
order to have an</span></div><div><span>almost decent UX you would have to prepare a \
first stage transaction that creates a nice (what is nice? \
&nbsp;It's</span></div><div><span>very hard to reason about) distribution of coin \
amounts. This is a big tradeoff between usability and \
cost</span></div><div><span>(granularity). Of course it's not new to CTV, It's an \
issue today with Revault. It's just a problem faced by</span></div><div><span>today's \
implementation(s) (i don't know of any other "real" vault implementation) of Bitcoin \
vaults that CTV</span></div><div><span>does not solve.</span></div><div><span>I \
realise that you might not care to receive coins on a single-sig Script and have a \
vaulting step in a</span></div><div><span>single-party situation. I guess i just \
think vaults are more interesting in organisational situations, where \
a</span></div><div><span>set of participants only marginally trust another one (that \
may be a subset) and want to both limit the amount</span></div><div><span>they have \
access to and apply policies on how they would use the \
funds.</span></div><div><br></div><div><br></div><div><span>Antoine</span></div><div><br></div><div><br></div><div><span>[0] \
All vaults architectures i know of are characterized by the necessity to unlock the \
funds in multiple</span></div><div><span>&nbsp; &nbsp; stages, one of which is \
timelocked.</span></div><div><span>[1] <a target="_blank" rel="noreferrer nofollow \
noopener" href="https://arxiv.org/abs/2005.11776">https://arxiv.org/abs/2005.11776</a></span></div><div><span>[2] \
<a target="_blank" rel="noreferrer nofollow noopener" \
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html"> \
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html</a></span></div><span>[3] \
<a target="_blank" rel="noreferrer nofollow noopener" \
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.ht \
ml">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html</a></span><br></div><div \
style="font-family: arial; font-size: 14px; color: rgb(34, 34, 34);"><br></div><div \
style="font-family: arial; font-size: 14px; color: rgb(34, 34, 34);"><br></div><div \
                class="protonmail_quote">
        ------- Original Message -------<br>
        Le lundi 25 avril 2022 Ă  6:57 PM, Nadav Ivgi &lt;nadav@shesek.info&gt; a \
ĂŠcrit :<br><br>  <blockquote class="protonmail_quote" type="cite">
            <div dir="ltr"><div><span class="gmail-im"><div dir="ltr">darosior via \
bitcoin-dev wrote:</div></span>&gt; <span class="gmail-im">i doubt CTV is necessary \
nor sufficient for this</span></div><div><span \
class="gmail-im"><br></span></div><div><span class="gmail-im">I would be interested \
to hear more on this.</span></div><div><span \
class="gmail-im"><br></span></div><div><span class="gmail-im">Is it not necessary \
because you can exchange and store pre-signed transactions \
instead?<br></span></div><div><span class="gmail-im"><br></span></div><div><span \
class="gmail-im">What purpose is it not <span class="gmail-im">sufficient for? There \
are some vault designs out there that are able to achieve interesting properties with \
CTV, like James O'Beirne's simple-ctv-vault:<br></span></span></div><div><span \
class="gmail-im"><span class="gmail-im"><br></span></span></div><div><span \
class="gmail-im"><span class="gmail-im"><a \
href="https://github.com/jamesob/simple-ctv-vault" rel="noreferrer nofollow noopener" \
target="_blank">https://github.com/jamesob/simple-ctv-vault</a></span></span></div><div><span \
class="gmail-im"><span class="gmail-im">(the basic design expressed in Minsc: <a \
href="https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4" rel="noreferrer \
nofollow noopener" target="_blank">https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4</a>)</span></span></div></div><br><div \
class="gmail_quote"><div class="gmail_attr" dir="ltr">On Fri, Apr 22, 2022 at 2:23 PM \
darosior via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" \
rel="noreferrer nofollow noopener" \
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; \
wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex" class="gmail_quote">I would like to know people's \
sentiment about doing (a very slightly tweaked version of) BIP118 in place of<br> (or \
before doing) BIP119.<br> <br>
SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. \
It presents proven and<br> implemented usecases, that are demanded and (please \
someone correct me if i'm wrong) more widely accepted than<br> CTV's.<br>
<br>
SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], \
can emulate CTV just fine.<br> Sure then you can't have bare or Segwit v0 CTV, and \
it's a bit more expensive to use. But we can consider CTV<br> an optimization of \
APO-AS covenants.<br> <br>
CTV advocates have been presenting vaults as the flagship usecase. Although as \
someone who've been trying to<br> implement practical vaults for the past 2 years i \
doubt CTV is necessary nor sufficient for this (but still<br> useful!), using APO-AS \
covers it. And it's not a couple dozen more virtual bytes that are going to matter \
for<br> a potential vault user.<br>
<br>
If after some time all of us who are currently dubious about CTV's stated usecases \
are proven wrong by onchain<br> usage of a less efficient construction to achieve the \
same goal, we could roll-out CTV as an optimization.  In<br> the meantime others will \
have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind<br> \
statechains, etc..[1]).<br> <br>
<br>
Given the interest in, and demand for, both simple covenants and better offchain \
protocols it seems to me that<br> BIP118 is a soft fork candidate that could benefit \
more (if not most of) Bitcoin users.<br> Actually i'd also be interested in knowing \
if people would oppose the APO-AS part of BIP118, since it enables<br> CTV's \
features, for the same reason they'd oppose BIP119.<br> <br>
<br>
[0] That is, to not commit to the other inputs of the transaction (via \
`sha_sequences` and maybe also<br> `sha_amounts`). Cf <a target="_blank" \
rel="noreferrer nofollow noopener" \
href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message \
">https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message</a>.<br>
 <br>
[1] <a target="_blank" rel="noreferrer nofollow noopener" \
href="https://anyprevout.xyz/">https://anyprevout.xyz/</a> "Use Cases" section<br> \
_______________________________________________<br> bitcoin-dev mailing list<br>
<a target="_blank" href="mailto:bitcoin-dev@lists.linuxfoundation.org" \
rel="noreferrer nofollow noopener">bitcoin-dev@lists.linuxfoundation.org</a><br> <a \
target="_blank" rel="noreferrer nofollow noopener" \
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
 </blockquote></div>

        </blockquote><br>
    </div>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[prev in list] [next in list] [prev in thread] [next in thread] 