path: root/68/51c7dae8204c448323c62ba83716853f9c4e4b

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AB5E5C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  3 May 2022 15:51:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8B6F54176F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  3 May 2022 15:51:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level: 
X-Spam-Status: No, score=-0.123 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, PDS_OTHER_BAD_TLD=1.975,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 R_4eFar247yy
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  3 May 2022 15:51:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [IPv6:2a00:1450:4864:20::12d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id C79F64176E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  3 May 2022 15:51:33 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id x17so31009899lfa.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 03 May 2022 08:51:33 -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=pFRTlepR1a7pfpLsY9MFYym0/VtK2PRT/37BoXtfMC0=;
 b=jbpcoyZPotujSoNkzXcNHBhQgka4rmW+u7xzyuw60uC2Fm4CwL+WEQi5WJTtGBQ3YW
 jwcJOFBx/U9ina1CP5wS2mN/1WXxfGPtMTM6ryX8AkoqxwmVN6uXKtpEnFEF58OaOkfY
 RMdfiR1gZa4grRtjdLnnIFGWP9vIKyyiUEPeQ/b7p1a5ZAMuy+oND4JleAOX8YeP+PNc
 sxofskiS3ESV3p8LzKf3/HLlNUz+hxGC3sZo/kgy8/bR6M9ODctTU7xbP4e7VS/rE6/a
 YaKt7G0bdU/4s3Q64j7QEElUYqWO1B6sExGr/HdTNfdvGj3p9X9lgA1iMr+OCfjp3C8o
 hTyA==
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=pFRTlepR1a7pfpLsY9MFYym0/VtK2PRT/37BoXtfMC0=;
 b=JsonWY+kIwuHjiGE4xSp7HfjhVHtIxXoaofPzVQ3OAjoqo7tplnCZDQEOTK7i6cgBr
 AtGQzbMfAkGDDEEzSRqZ6ErLvWeBhxKYoojnEKtHxXTYFiprojmj+SY9Oe47+5wKoiIy
 vYOjpLEX0Rx5IYqs+cBXCGbOYxo6SFaKjvZpHutlAT7778SDHiGKJy05c5pbaDAkqfL5
 6R321H7tVT9eOhi1Y1OungmH10qDhLPoqs+j9saB7EJo2WrCdTVGsKLayuvniYK6paXt
 eBAYMbnVlMIjhPlUqQ7x7RXThsqJh8VEnXMR6Sckfi3mNZURlhi+mR9U+wvKsvj35/Vj
 8z7g==
X-Gm-Message-State: AOAM531P80/QgRn6iUEfFwGLNWFRSOckTQBOZLZIvz7NSJQUMr9DUlsg
 cgJpRQ28+lpWPAXTLmMfuX08S0iKr3QdVf1Ko3Q=
X-Google-Smtp-Source: ABdhPJw8EdoV9/BKytujcR5RaJXN+RywXM60AbD9ghj3DN76Mv9z3BP7TYkiZK6JBhnEzXWYufcMm54sZBpmLxH/rp0=
X-Received: by 2002:ac2:5ecc:0:b0:472:3c01:9a2e with SMTP id
 d12-20020ac25ecc000000b004723c019a2emr11076330lfq.245.1651593091494; Tue, 03
 May 2022 08:51:31 -0700 (PDT)
MIME-Version: 1.0
References: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com>
In-Reply-To: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Tue, 3 May 2022 08:51:18 -0700
Message-ID: <CAD5xwhjoMqja6Q8Lqtf9TzCWA9LYn+bUPPs-5DzX5mJUfFYN_Q@mail.gmail.com>
To: darosior <darosior@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000088368905de1d7bad"
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
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, 03 May 2022 15:51:35 -0000

--00000000000088368905de1d7bad
Content-Type: text/plain; charset="UTF-8"

Antoine,

One high level reason to not prefer APO is that it gets 'dangerously close'
to fully recursive covenants.

E.g., just by tweaking APO to use a Schnorr signature without PK
commitment, Pubkey Recovery would be possible, and fully recursive
covenants could be done.

Short of that type of modification, you can still do a "trusted setup" key
deletion covenant with APO and have a fully recursive covenant set up. E.g.

<1 || N-N MuSig> APO

where the N-N MuSig pregenerates a signature of a transaction that commits
to an output with itself, e.g., using SIGHASH_SINGLE.

By itself, this is not super useful, but does create the type of thing that
people might worry about with a recursive covenant since after
initialization it is autonomous.

One use case for this might be, for example, a spacechain backbone that
infinitely iterates, so it isn't entirely useless.

If other opcodes are added, such as OP_IN_OUT_AMOUNT, then you can get all
sorts of recursive covenant interesting stuff on top of that, since you
could pre-sign e.g. for a quanitzed vault a number of different
deposit/withdraw programs as well as increasing balances depending on
timeout waited.


Therefore, I think reasonable people might discriminate the "complexity
class" of the design space available with just CTV v.s. APO.

In contrast, the approach of smaller independent steps:

1) Adding CTV
2) Adding CSFS (enables APO-like behavior, sufficient for Eltoo)
3) Adding flags to CTV, similar to TXHASH, or just adding TXHASH (enables
full covenants)
4) Ergonomic OPCodes for covenants like TLUV, EcTweak, MAST building, etc
(enables efficient covenants)

is a much more granular path where we are able to cleanly 'level up' into
each covenant complexity class only if we deem it to be safe.

<redacted>comment about timelines to produce a modified APO</redacted>

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>

On Fri, Apr 22, 2022 at 4:23 AM 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
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Antoine,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">One high =
level reason to not prefer APO is that it gets &#39;dangerously close&#39; =
to fully recursive covenants.</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000">E.g., just by tweaking APO to use a Sch=
norr signature without PK commitment, Pubkey Recovery would be possible, an=
d fully recursive covenants could be done.</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">Short of that type of modi=
fication, you can still do a &quot;trusted setup&quot; key deletion covenan=
t with APO and have a fully recursive covenant set up. E.g.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">&lt;1 || =
N-N MuSig&gt; APO</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000">where the N-N MuSig pregenerates a signature of a t=
ransaction that commits to an output with itself, e.g., using SIGHASH_SINGL=
E.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">By itself, this is not super useful, but does create the type of t=
hing that people might worry about with a recursive covenant since after in=
itialization it is autonomous.</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">One use case for this might be, for ex=
ample, a spacechain backbone that infinitely iterates, so it isn&#39;t enti=
rely useless.</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000">If other opcodes are added, such as OP_IN_OUT_AMOUNT, t=
hen you can get all sorts of recursive covenant interesting stuff on top of=
 that, since you could pre-sign e.g. for a quanitzed vault a number of diff=
erent deposit/withdraw programs as well as increasing balances depending on=
 timeout waited.</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Therefore=
, I think reasonable people might discriminate the &quot;complexity class&q=
uot; of the design space available with just CTV v.s. APO.<br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">In con=
trast, the approach of smaller independent steps:</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000">1) Adding CTV</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000">2) Adding CSFS (enables APO-like behavior,=
 sufficient for Eltoo)</div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000">3) Adding flag=
s to CTV, similar to TXHASH, or just adding TXHASH (enables full covenants)=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">4) Ergonomic OPCodes for covenants l=
ike TLUV, EcTweak, MAST building, etc (enables efficient covenants)</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">i=
s a much more granular path where we are able to cleanly &#39;level up&#39;=
 into each covenant complexity class only if we deem it to be safe.</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">&=
lt;redacted&gt;comment about timelines to produce a modified APO&lt;/redact=
ed&gt;</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">Best,</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">Jeremy</div><br clear=3D"all"><div><div dir=3D"ltr=
" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"=
ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@J=
eremyRubin</a><br></div></div></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 22, 2022 at 4:23 AM darosio=
r via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex">I would like to know people&#39;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 ove=
r 6 years. It presents proven and<br>
implemented usecases, that are demanded and (please someone correct me if i=
&#39;m wrong) more widely accepted than<br>
CTV&#39;s.<br>
<br>
SIGHASH_ANYPREVOUTANYSCRIPT, if its &quot;ANYONECANPAY&quot; behaviour is m=
ade optional [0], can emulate CTV just fine.<br>
Sure then you can&#39;t have bare or Segwit v0 CTV, and it&#39;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&#39;ve been trying to<br>
implement practical vaults for the past 2 years i doubt CTV is necessary no=
r sufficient for this (but still<br>
useful!), using APO-AS covers it. And it&#39;s not a couple dozen more virt=
ual 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&#39;s stat=
ed usecases are proven wrong by onchain<br>
usage of a less efficient construction to achieve the same goal, we could r=
oll-out CTV as an optimization.=C2=A0 In<br>
the meantime others will have been able to deploy new applications leveragi=
ng ANYPREVOUT (Eltoo, blind<br>
statechains, etc..[1]).<br>
<br>
<br>
Given the interest in, and demand for, both simple covenants and better off=
chain protocols it seems to me that<br>
BIP118 is a soft fork candidate that could benefit more (if not most of) Bi=
tcoin users.<br>
Actually i&#39;d also be interested in knowing if people would oppose the A=
PO-AS part of BIP118, since it enables<br>
CTV&#39;s features, for the same reason they&#39;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 href=3D"https://github.com/bitcoin/bips/blob/master/b=
ip-0118.mediawiki#signature-message" rel=3D"noreferrer" target=3D"_blank">h=
ttps://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-mes=
sage</a>.<br>
<br>
[1] <a href=3D"https://anyprevout.xyz/" rel=3D"noreferrer" target=3D"_blank=
">https://anyprevout.xyz/</a> &quot;Use Cases&quot; section<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>

--00000000000088368905de1d7bad--