path: root/16/fa01dda8306efa8b4b8cdacc2efbb6e12018b2

Return-Path: <nadav@shesek.info>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C5500C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 May 2022 14:25:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id A5271827E0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 May 2022 14:25:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level: 
X-Spam-Status: No, score=0.3 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.997,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=neutral
 reason="invalid (public key: not available)" header.d=shesek.info
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id R63fw6FEUplj
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 May 2022 14:25:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com
 [IPv6:2607:f8b0:4864:20::12b])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D4C7182771
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 May 2022 14:25:54 +0000 (UTC)
Received: by mail-il1-x12b.google.com with SMTP id s14so455786ild.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 01 May 2022 07:25:54 -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=9sa8bfmkh8T3JLTpf3gOz+skE+VxIUgUcbTZ8UZD8Ik=;
 b=h5YaeON5aeEz/bpJICk7A6uhbLiU/8GHECbD6/wz4a1jQJTuNBNhamfu5EsgY9+l+J
 l9CDMaqiBrs2NTQYxl7C2MkGEOHg5OGioQq/pyAa1hVbmG99U2HdS6cZ6q0q+/QFm0Q5
 9mPxUrDF8dRacv9zYikImkrWhYFhv8UZ8yr4U=
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=9sa8bfmkh8T3JLTpf3gOz+skE+VxIUgUcbTZ8UZD8Ik=;
 b=wyYdU486XXYq+ilTBiEaPv3EVGbQbvZfH70C0e0HPUilAG55NOFhHEzMqjYcRkZTyY
 +cMcS8IKXtBs/26cZrCPDN2TonfvUfl+dJMgUKIuNCFqbX8sCuIeFTDo/R6iYBt7t62+
 K/DxFblzCgDqSe2LToO7WpNYjTBS3Ip8HA3ztljtaxA0nw5FjWyxrJ/MDakpqC41ugRc
 x5LImrEDbyN3mObvbNqYITDeHlnoIb/ub+fWEWOdvcXgDkY06SCAfM7AFrU7xq5WVFpg
 WF9C71bfVx+F8ikq7N9PoFGTepGnjl05OTKEh9QIVcbl9G+12bchYy3sLUfTeyScLbUe
 8FVQ==
X-Gm-Message-State: AOAM532oIhu69W1g6d+rd/1BMu63HMxhRouqq88Lp3hPAXNlkJ9eG0MV
 99R30PU9Udg5F2rSQVpUY4KBCbhS/7sa8siYntVxpQ==
X-Google-Smtp-Source: ABdhPJxjoEA0S8l87SbCRntG8Zvk+D7C15/aIPXnoSiQAg+Yijgx0u2RN5HjT2+Y6YrNTwdJjuwCA2yV0RdG0NBE8G4=
X-Received: by 2002:a05:6e02:148c:b0:2cd:9399:369b with SMTP id
 n12-20020a056e02148c00b002cd9399369bmr3018966ilk.300.1651415153677; Sun, 01
 May 2022 07:25:53 -0700 (PDT)
MIME-Version: 1.0
References: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com>
 <CAGXD5f1KgDzY5sc-zknHYUSiSa7kWsXOHkg7kDakY3Kh5QtxTQ@mail.gmail.com>
In-Reply-To: <CAGXD5f1KgDzY5sc-zknHYUSiSa7kWsXOHkg7kDakY3Kh5QtxTQ@mail.gmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Sun, 1 May 2022 17:25:42 +0300
Message-ID: <CAGXD5f1EquTAx0j0uc_jzWr9ZG8WRutUxznpmXn_7xuav6H4cw@mail.gmail.com>
To: darosior <darosior@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009caabc05ddf40da0"
X-Mailman-Approved-At: Sun, 01 May 2022 15:29:58 +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: Sun, 01 May 2022 14:25:57 -0000

--0000000000009caabc05ddf40da0
Content-Type: text/plain; charset="UTF-8"

> via `sha_sequences`

Since you cannot expect txid stability with >1 inputs either way[0], it
should be sufficient to commit just to the current input's
nSequence/scriptSig to get txid stability for single input transactions. I
chatted with Jeremy about this and he appears to agree.

Not committing to the nSequence of other inputs gives them the freedom to
set it independently, so for example you can spend a CSV-encumbered output
alongside the covenant. And there seems to be no downside to doing this [1].

APO/APOAS already commits to the nSequence of the current input. And since
APO is Taproot-only, the scriptSig of the covenant input is guarrnated to
be empty, so it is also already committed to in a way.

However, without committing to all the nSequences which implicitly commits
to the number of inputs, the number has to be committed separately.

So my suggestion is to explicitly commit to the number of inputs, instead
of commiting to `sha_sequences`.

Cheers
shesek

[0] the additional input(s) will be third-party malleable, since their
prevouts can be replaced with an entirely different txid:vout
[1] BIP 119's rationale for committing to the nSequences is txid
malleability:
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committing-to-the-sequences-hash



On Sat, Apr 30, 2022 at 11:09 AM Nadav Ivgi <nadav@shesek.info> wrote:

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

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

<div dir=3D"ltr"><div><span class=3D"gmail-im"></span></div><div><span clas=
s=3D"gmail-im">&gt; via `sha_sequences`</span></div><div><span class=3D"gma=
il-im"><br></span></div><div><span class=3D"gmail-im">Since you cannot expe=
ct txid stability with &gt;1 inputs either way[0], it should be sufficient =
to commit just to the current input&#39;s nSequence/scriptSig to get txid s=
tability for single input transactions. I chatted with Jeremy about this an=
d he appears to agree.<br></span></div><div><span class=3D"gmail-im"><br></=
span></div><div><div><span class=3D"gmail-im">Not committing to the <span c=
lass=3D"gmail-im">nSequence</span> of other inputs gives them the freedom t=
o set it independently, so for example you can spend a CSV-encumbered outpu=
t alongside the covenant. And there seems to be no downside to doing this [=
1].<br></span></div><div><span class=3D"gmail-im"><br></span></div><span cl=
ass=3D"gmail-im"></span></div><div><span class=3D"gmail-im"></span></div><d=
iv><span class=3D"gmail-im">APO/APOAS already commits to the <span class=3D=
"gmail-im"><span class=3D"gmail-im">nSequence</span></span> of the current =
input. And since APO is Taproot-only, the scriptSig of the covenant input i=
s guarrnated to be empty, so it is also already committed to in a way.<br><=
/span></div><div><span class=3D"gmail-im"><br></span></div><div><span class=
=3D"gmail-im">However, without committing to all the <span class=3D"gmail-i=
m"><span class=3D"gmail-im"><span class=3D"gmail-im">nSequences which impli=
citly commits to the number of inputs, the number has to be committed separ=
ately.<br></span></span></span></span></div><div><span class=3D"gmail-im"><=
span class=3D"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im"><=
br></span></span></span></span></div><div><span class=3D"gmail-im"><span cl=
ass=3D"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im">So my su=
ggestion is to <span class=3D"gmail-im"><span class=3D"gmail-im"><span clas=
s=3D"gmail-im"><span class=3D"gmail-im">explicitly </span></span></span></s=
pan>commit to the number of inputs, instead of commiting to `<span class=3D=
"gmail-im">sha_sequences`.</span></span></span></span></span></div><div><sp=
an class=3D"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im"><sp=
an class=3D"gmail-im"><span class=3D"gmail-im"><br></span></span></span></s=
pan></span></div><div><span class=3D"gmail-im"><span class=3D"gmail-im"><sp=
an class=3D"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im">Che=
ers</span></span></span></span></span></div><div><span class=3D"gmail-im"><=
span class=3D"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im"><=
span class=3D"gmail-im">shesek</span></span></span></span></span></div><div=
><span class=3D"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im"=
><span class=3D"gmail-im"><span class=3D"gmail-im"><br></span></span></span=
></span></span></div><div><span class=3D"gmail-im"><span class=3D"gmail-im"=
><span class=3D"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im"=
>[0] <span class=3D"gmail-im">the additional input(s) will be third-party m=
alleable, since their prevouts can be replaced with an entirely different t=
xid:vout</span></span></span></span></span></span></div><div><span class=3D=
"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im"><span class=3D=
"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im">[1] BIP 119&#3=
9;s rationale<span class=3D"gmail-im"><span class=3D"gmail-im"><span class=
=3D"gmail-im"><span class=3D"gmail-im"><span class=3D"gmail-im"><span class=
=3D"gmail-im"> for committing to the nSequences</span></span></span></span>=
</span></span> is txid malleability: <a href=3D"https://github.com/bitcoin/=
bips/blob/master/bip-0119.mediawiki#committing-to-the-sequences-hash">https=
://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committing-to-the=
-sequences-hash</a></span></span></span></span></span></span></div><br><div=
><span class=3D"gmail-im"><br></span></div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Apr 30, 2022 at 11:09 AM=
 Nadav Ivgi &lt;<a href=3D"mailto:nadav@shesek.info">nadav@shesek.info</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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-family:mon=
ospace">APOAS|SINGLE</span> (with the <span style=3D"font-family:monospace"=
>ANYONECANPAY</span> behaviour and without covering the spent input index) =
has some interesting uses for cases where the covenant only needs to restri=
ct a single output (so useful for e.g. vaults or spacechains, but not for b=
atch channels or congestion control).</div><div><br></div><div>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 vaul=
ted outputs in a single transaction.<br></div><div><br></div><div>For space=
chains, it makes it possible to add the spaceblock hash OP_RETURN and pay f=
ees directly in the tx chain, instead of having to use an additional tx to =
prepare an output that gets spent in the tx chain=C2=A0 (see the diagram in=
 [0]).</div><div></div></div><div><br></div><div>&gt; via `sha_sequences` a=
nd maybe also `sha_amounts`</div><div><br></div><div>CTV does not commit to=
 the input amounts. This has some practical implications:<br></div><div><br=
></div><div>1. If it is committed, sending an even slightly incorrect amoun=
t will make the covenant-encumbered spend path unusable.</div><div><br></di=
v><div>With CTV, sending a slightly lower amount results in slightly lower =
fees, while any extra gets spent/burned on fees. The covenant spend path on=
ly becomes unusable if the amount is too low to cover for the outputs (+rel=
ay fee for it to also be standard).<br></div><div><br></div><div>2. The abi=
lity to allow for additional inputs with unknown amounts makes it possible =
to fee-bump the covenant spending transaction (with whole utxos and no chan=
ge). You can have one tapleaf for spending the covenant output alone, and a=
nother 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 described i=
n (1), by adding an input that covers the original intended amount.<br></di=
v><div><br></div><div>So my suggestion would be to either not cover `sha_am=
ounts` in the msg hash, or to make it optional behind a flag.</div><div></d=
iv><div><br></div><div>shesek</div><div><br></div><div>[0] <a href=3D"https=
://github.com/fiatjaf/simple-ctv-spacechain" target=3D"_blank">https://gith=
ub.com/fiatjaf/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 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I woul=
d 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>
</blockquote></div>

--0000000000009caabc05ddf40da0--