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 <j@rubin.io>
Date: Tue, 26 Apr 2022 13:13:26 -0700
Message-ID: <CAD5xwhi6DYVm3sONub0x4s=Ef0TupA4j4KxY616RnacXr1GsLA@mail.gmail.com>
To: darosior <darosior@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000bc41805dd945442"
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Precedence: list

--0000000000000bc41805dd945442
Content-Type: text/plain; charset="UTF-8"

I can't find all of my earlier references around this, I thought I made a
thread on it, but as a reminder, my thoughts for mild tweaks to APO that
make it a bit less hacky are as follows:

- Remove OP_1 key punning and replace it with OP_GENERATOR and
OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is useful
generically, because I may want to reuse the internal key in conjunction
with a script path in some circumstances.
- Add an additional sequence field that is specific to a signature with no
other consensus meaning, so APO can be used with absolute timelocks. For
example, this makes it impossible for more than one ratchet to be
aggregated within a single transaction under any circumstance if their
sequences differ (not sure this is a good example, but an example
nonetheless).
- Replace tagged keys for APO with either a Checksig2 or a separate feature
flag that enables or disables APO behavior so that we can have programmatic
control over if APO is allowed for a given key (e..g., OP_IF <N> CSV DROP
CHECKSIG2 OP_ELSE CHECKSIG OP_ENDIF enables APO to be turned on after a
certain time, perhaps for a pre-approved backup transaction).

Overall, this would make eltoo ratchets look something like this:

<sig> <seq> OP_1 OP_INTERNALKEY OP_CHECKSIG2VERIFY <N> OP_GREATERTHAN

where checksig2 leaves seq on the stack which can be used to enforce the
ratchet.

and covenants like:

<sig> OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY







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
>

--0000000000000bc41805dd945442
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">I can&#39;t find all of m=
y earlier references around this, I thought I made a thread on it, but as a=
 reminder, my thoughts for mild tweaks to APO that make it a bit less hacky=
 are as follows:</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">- Remove OP_1 key punning and replace it with OP_GEN=
ERATOR and OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is u=
seful generically, because I may want to reuse the internal key in conjunct=
ion with a script path in some circumstances.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">- Add an additional sequence field that is specific to a signature=
 with no other consensus meaning, so APO can be used with absolute timelock=
s. For example, this makes it impossible for more than one ratchet to be ag=
gregated within a single transaction under any circumstance if their sequen=
ces differ (not sure this is a good example, but an example nonetheless).</=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">- Replace tagged keys for APO with eit=
her a Checksig2 or a separate feature flag that enables or disables APO beh=
avior so that we can have programmatic control over if APO is allowed for a=
 given key (e..g., OP_IF &lt;N&gt; CSV DROP CHECKSIG2 OP_ELSE CHECKSIG OP_E=
NDIF enables APO to be turned on after a certain time, perhaps for a pre-ap=
proved backup transaction).</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-ser=
if;font-size:small;color:#000000">Overall, this would make eltoo ratchets l=
ook something like this:</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000">&lt;sig&gt; &lt;seq&gt; OP_1 OP_INTERNALKEY =
OP_CHECKSIG2VERIFY &lt;N&gt; OP_GREATERTHAN</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">where checksig2 leaves se=
q on the stack which can be used to enforce the ratchet.</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000">and covenant=
s like:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,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;c=
olor:#000000">&lt;sig&gt; OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY</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"><=
br></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_def=
ault" 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"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 22, 2022 at 4:23 AM darosior v=
ia bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:=
1ex">I would like to know people&#39;s sentiment about doing (a very slight=
ly 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>

--0000000000000bc41805dd945442--