path: root/e1/e11e369b5ee8897c5328c1d3b4d953ed7cfa34

Return-Path: <nadav@shesek.info>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BED93C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Apr 2022 08:09:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 97C9D41CAD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Apr 2022 08:09:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.278
X-Spam-Level: 
X-Spam-Status: No, score=0.278 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
 HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.975,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=neutral
 reason="invalid (public key: not available)" header.d=shesek.info
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 LbTkCuePIquV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Apr 2022 08:09:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com
 [IPv6:2607:f8b0:4864:20::d30])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 2E61E41BED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Apr 2022 08:09:39 +0000 (UTC)
Received: by mail-io1-xd30.google.com with SMTP id c125so11849481iof.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Apr 2022 01:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=u9k/fQgfIeTbo9PPooY0X+bEep16DBMydBnay4Gxp9M=;
 b=XHWT68SwvrISnAK0y8yALxMmmn/c3jg8IeJvwmfW3tCt3k3135OxwpjotOHDd4r0nD
 KEtKd0fLchvjCCOfHTGQgGPJZj0g/54tPX44ZRLy+MAnXAMCpO3AoV2wDLpSHYuX0QAP
 CeH0WSFVRFTyO2oLnVvDzhtLVoqmE08Tdjlwk=
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=u9k/fQgfIeTbo9PPooY0X+bEep16DBMydBnay4Gxp9M=;
 b=Vz0X7tVmqZcR2PASgoV3rQjklli5LNOMD122vy/h989OENPgfYisTV7JCBrXQDPwTl
 f6zHwkjv6bdDilw6H3Ej69ZS07nAgxj8DTHpmt3Y8Tqq0RVa6tc1U4yVd3wIF9l9Bw7U
 2O2B/6bZluJl2i+pvH4eL1+LmRpUjHtMt/8DiMdLbM75l2FnxcmnuKCN/hO9O4OzTUwy
 XYDdecjinL1O+QLftms8D5TMu8yadLhYTJ1U5dWg9TlKtt3HKVBZRXujh6SXYUXLzoTP
 6dPBjWp1MHzZENxcyfmI29r0I+5QIU03+6r9HkdbShfcRlSeHoNOB04wMJzXABENpnhR
 n9TQ==
X-Gm-Message-State: AOAM533RLOLG13L8v4/hcPks6MQo0A0CnSRu/5yzQf0Nnr8jiNtMdatj
 y+EZgQ9DSX8LHGFRGK6zInPS7BoFUnjp2W1tbMw5jQ==
X-Google-Smtp-Source: ABdhPJxwDxLIRE1yQDe8YOARFqLEJ50w6xlOV0/XQKzd52EtyE2jgBFZU9Q9wrllb+SdEoji5W4RjQ2jeyCTMeZOxYw=
X-Received: by 2002:a05:6638:2411:b0:32a:cd11:d04d with SMTP id
 z17-20020a056638241100b0032acd11d04dmr1301560jat.70.1651306177893; Sat, 30
 Apr 2022 01:09:37 -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: Nadav Ivgi <nadav@shesek.info>
Date: Sat, 30 Apr 2022 11:09:26 +0300
Message-ID: <CAGXD5f1KgDzY5sc-zknHYUSiSa7kWsXOHkg7kDakY3Kh5QtxTQ@mail.gmail.com>
To: darosior <darosior@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000262bd105dddaae3e"
X-Mailman-Approved-At: Sat, 30 Apr 2022 08:47:21 +0000
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: Sat, 30 Apr 2022 08:09:40 -0000

--000000000000262bd105dddaae3e
Content-Type: text/plain; charset="UTF-8"

Hi darosior,

It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY behaviour
and without covering the spent input index) has some interesting uses for
cases where the covenant only needs to restrict a single output (so useful
for e.g. vaults or spacechains, but not for batch channels or congestion
control).

For example in the vault use-case, it makes it possible to bump fees on the
unvault tx by adding more inputs and a change output, as well as unvault
multiple vaulted outputs in a single transaction.

For spacechains, it makes it possible to add the spaceblock hash OP_RETURN
and pay fees directly in the tx chain, instead of having to use an
additional tx to prepare an output that gets spent in the tx chain  (see
the diagram in [0]).

> via `sha_sequences` and maybe also `sha_amounts`

CTV does not commit to the input amounts. This has some practical
implications:

1. If it is committed, sending an even slightly incorrect amount will make
the covenant-encumbered spend path unusable.

With CTV, sending a slightly lower amount results in slightly lower fees,
while any extra gets spent/burned on fees. The covenant spend path only
becomes unusable if the amount is too low to cover for the outputs (+relay
fee for it to also be standard).

2. The ability to allow for additional inputs with unknown amounts makes it
possible to fee-bump the covenant spending transaction (with whole utxos
and no change). You can have one tapleaf for spending the covenant output
alone, and another one for attaching an extra fee input to it.

This also makes it possible to resolve the under-payment issue described in
(1), by adding an input that covers the original intended amount.

So my suggestion would be to either not cover `sha_amounts` in the msg
hash, or to make it optional behind a flag.

shesek

[0] https://github.com/fiatjaf/simple-ctv-spacechain

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
>

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

<div dir=3D"ltr"><div>Hi darosior,<br></div><div></div><div><br></div><div>=
</div><div><div>It&#39;s interesting to note that <span style=3D"font-famil=
y:monospace">APOAS|SINGLE</span> (with the <span style=3D"font-family:monos=
pace">ANYONECANPAY</span> behaviour and without covering the spent input in=
dex) has some interesting uses for cases where the covenant only needs to r=
estrict a single output (so useful for e.g. vaults or spacechains, but not =
for batch channels or congestion control).</div><div><br></div><div>For exa=
mple in the vault use-case, it makes it possible to bump fees on the unvaul=
t tx by adding more inputs and a change output, as well as unvault multiple=
 vaulted outputs in a single transaction.<br></div><div><br></div><div>For =
spacechains, it makes it possible to add the spaceblock hash OP_RETURN and =
pay fees directly in the tx chain, instead of having to use an additional t=
x to prepare an output that gets spent in the tx chain=C2=A0 (see the diagr=
am in [0]).</div><div></div></div><div><br></div><div>&gt; via `sha_sequenc=
es` and maybe also `sha_amounts`</div><div><br></div><div>CTV does not comm=
it to the input amounts. This has some practical implications:<br></div><di=
v><br></div><div>1. If it is committed, sending an even slightly incorrect =
amount will make the covenant-encumbered spend path unusable.</div><div><br=
></div><div>With CTV, sending a slightly lower amount results in slightly l=
ower fees, while any extra gets spent/burned on fees. The covenant spend pa=
th only becomes unusable if the amount is too low to cover for the outputs =
(+relay fee for it to also be standard).<br></div><div><br></div><div>2. Th=
e ability to allow for additional inputs with unknown amounts makes it poss=
ible to fee-bump the covenant spending transaction (with whole utxos and no=
 change). You can have one tapleaf for spending the covenant output alone, =
and another one for attaching an extra fee input to it.</div><div><br></div=
><div>This also makes it possible to resolve the under-payment issue descri=
bed in (1), by adding an input that covers the original intended amount.<br=
></div><div><br></div><div>So my suggestion would be to either not cover `s=
ha_amounts` in the msg hash, or to make it optional behind a flag.</div><di=
v></div><div><br></div><div>shesek</div><div><br></div><div>[0] <a href=3D"=
https://github.com/fiatjaf/simple-ctv-spacechain">https://github.com/fiatja=
f/simple-ctv-spacechain</a></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 22, 2022 at 2:23 PM 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:1px sol=
id rgb(204,204,204);padding-left:1ex">I would like to know people&#39;s sen=
timent 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>

--000000000000262bd105dddaae3e--