path: root/a0/e852b946ae003aee685466e3ae5f85fd695284

Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 801EAC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 13:34:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 670D360D6E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 13:34:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.091
X-Spam-Level: 
X-Spam-Status: No, score=-0.091 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.997,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_MIME_MALF=0.01] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CTDYD3MkVgnn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 13:34:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [IPv6:2a00:1450:4864:20::52a])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 0B95D60AA8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 13:34:38 +0000 (UTC)
Received: by mail-ed1-x52a.google.com with SMTP id p18so13258042edr.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 06:34:38 -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=z+2j0kCLe6pT5IOXFBgOM4Gg2lwXJ13n5+k0lIQL/oQ=;
 b=dRiz8RISlx4d+w5nXRqSqhowXTaYEZyI5zFgmU/1fJHrwnEQBvXa0fEviJ4++WcPnr
 nWIFmFFvv/GEIYtrI7WX04ZULR1XIPLyL/9GQt35aQfELWLB7mDNrmqhBn+ZMh/PjGpM
 lHgTneGIm9NZ6zy76eALGVRBd4yH5KQ8plArn8elfxMXTiMVG+G5d/J1ybfX5bh5aMDd
 rxMR0JzLOBTI2KR0namcGm4B01duKEuF7IkO8unkBblYovMzlG3IiTteQYmHRS8S0bVu
 H66DuB9fX8Gh8O1zwtHEEL3FoaFbeTGoXiQC3loWvPJ/VowqEAsRvv0Xt95SSrHJD1HU
 JOpw==
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=z+2j0kCLe6pT5IOXFBgOM4Gg2lwXJ13n5+k0lIQL/oQ=;
 b=JqmRhqBAy0LyGiWFpoij+pSzIX36uKH5fI/iCUlgR1V4GUyGE3fB1kHxJkdy1/fs0K
 nD6u2DPeqy8gJ9bkq/LpgZEypO5v2uCnPIzABsNKHp5bcfnKMLe0rg4oz14ecptXNmPI
 AG3AhBj2s2maiQP++Vg7pnXfXNRjbUZ4lj2v0rkuQ1U2zNBtG4J3khbUTWB5Qs5ykxYN
 Uylss174kcBx0JrBOkCTw6De7Y7Is6FM+Tc9uFN/CdChjPNZajwm5qvtv7oB1YWAzmpo
 qnYfY+NODqMIpoG+Gx85ycj9mzbDgaIfcPv+Vj0EZMFeZD2ezgAJHkbQvTb5EQ/pccrE
 Ml4w==
X-Gm-Message-State: AOAM532v1b3sTC7JpdJQIXIywlNvWWR8/Xs6zZlxXPxAvph7HwoLmZ2B
 c1+DmNjvZtDq/uipw+5cqLL/PY06QMOBCgUv78U4HiyPWaK+60BL
X-Google-Smtp-Source: ABdhPJyLZkwocgaqiwo+26TNgrsFCG5bVZ1p0N5I9qkDs6y2Tu2ShovnjOA1uX5hgjyJGK+CZlUorBoGDbUek9ITQy4=
X-Received: by 2002:a05:6402:5c9:b0:420:aac6:257b with SMTP id
 n9-20020a05640205c900b00420aac6257bmr18942997edx.128.1650893677033; Mon, 25
 Apr 2022 06:34:37 -0700 (PDT)
MIME-Version: 1.0
References: <QfDkla2cgggQt7kknw7oYUtoDCG0x4JmOdhtjddhFBu9XDGsmX9ZvxMcu4O_D9QnsxVohSSRZPLPNfv14z78uNMAU3iWWCVU5VH9IlywEro=@protonmail.com>
In-Reply-To: <QfDkla2cgggQt7kknw7oYUtoDCG0x4JmOdhtjddhFBu9XDGsmX9ZvxMcu4O_D9QnsxVohSSRZPLPNfv14z78uNMAU3iWWCVU5VH9IlywEro=@protonmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Mon, 25 Apr 2022 17:34:25 +0400
Message-ID: <CAFMkqK-pHDcXvSUrEyzrS8OsmW-0xa2o=MGYq3o_awXmnANc_Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002e7eb405dd7aa3b3"
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: Mon, 25 Apr 2022 13:34:40 -0000

--0000000000002e7eb405dd7aa3b3
Content-Type: text/plain; charset="UTF-8"

Hi pushd.
Would you mind clarifying what you mean by BIP118 being a premature idea?
SIGHASH_ANYPREVOUT, or SIGHASH_NOINPUT, as it was called back then, was
first proposed in the original Lightning Network whitepaper back in 2015.
It has been discussed on and off for many years now. I would not call it a
premature idea.

Now, the revised "Taprooted" version called ANYPREVOUT is a couple of years
old, so going with the NOINPUT version could be a safer bet (though that's
a bit ridiculous in my opinion).

Regarding that you do not find use-cases interesting. That's all fine I
suppose, but in the Lightning Network scene, I think it's fair to say that
there's widespread enthusiasm in getting a working eltoo solution, which
necessitates something like NOINPUT/ANYPREVOUT.
And even if eltoo wouldn't happen, enabling spacechains, covenants and
blind statechains seem like sufficient use-cases to me.

Cheers
Hampus

On Fri, Apr 22, 2022 at 9:32 PM pushd 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.
>
>
> NACK for the below reasons:
>
> - Premature idea
> - I do not find use cases interesting
> - We are still in research phase of implementing covenants in bitcoin and
> looking for the best proposal
> - Taproot soft fork was recently activated and its too soon
> - Not enough documentation available
> - Could not find any pull request in core for BIP 118 that can be reviewed
> - Not enough tools available for testing
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> ------- Original Message -------
> On Friday, April 22nd, 2022 at 5:30 PM,
> bitcoin-dev-request@lists.linuxfoundation.org wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
> Today's Topics:
>
> 1. ANYPREVOUT in place of CTV (darosior)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 22 Apr 2022 11:11:41 +0000
> From: darosior darosior@protonmail.com
>
> To: Bitcoin Protocol Discussion
> bitcoin-dev@lists.linuxfoundation.org
>
> Subject: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID:
>
> p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com
>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 83, Issue 40
> *******************************************
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi pushd.</div><div>Would you mind c=
larifying what you mean by BIP118 being a premature idea?</div><div>SIGHASH=
_ANYPREVOUT, or SIGHASH_NOINPUT, as it was called back then, was first prop=
osed in the original Lightning Network whitepaper back in 2015.</div><div>I=
t has been discussed on and off for many years now. I would not call it a p=
remature idea.<br></div><div><br></div><div>Now, the revised &quot;Taproote=
d&quot; version called ANYPREVOUT is a couple of years old, so going with t=
he NOINPUT version could be a safer bet (though that&#39;s a bit ridiculous=
 in my opinion).<br></div><div><br></div><div>Regarding that you do not fin=
d use-cases interesting. That&#39;s all fine I suppose, but in the Lightnin=
g Network scene, I think it&#39;s fair to say that there&#39;s widespread e=
nthusiasm in getting a working eltoo solution, which necessitates something=
 like NOINPUT/ANYPREVOUT.</div><div>And even if eltoo wouldn&#39;t happen, =
enabling spacechains, covenants and blind statechains seem like sufficient =
use-cases to me.<br></div><div><br></div><div>Cheers</div><div>Hampus<br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Fri, Apr 22, 2022 at 9:32 PM pushd via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div style=3D"font-family:arial;font-size:14px"><blockquote>
<p>I would like to know people&#39;s sentiment about doing (a very slightly=
 tweaked version of) BIP118 in place of (or before doing) BIP119.</p>
</blockquote>
<p><br>
NACK for the below reasons:<br>
<br>
- Premature idea<br>
- I do not find use cases interesting<br>
- We are still in research phase of implementing covenants in bitcoin and l=
ooking for the best proposal<br>
- Taproot soft fork was recently activated and its too soon<br>
- Not enough documentation available<br>
- Could not find any pull request in core for BIP 118 that can be reviewed<=
br>
- Not enough tools available for testing<br>
<br>
<br>
pushd<br>
---<br>
<br>
parallel lines meet at infinity?<br>
<br>
------- Original Message -------<br>
On Friday, April 22nd, 2022 at 5:30 PM, <a href=3D"mailto:bitcoin-dev-reque=
st@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.l=
inuxfoundation.org</a> wrote:<br>
<br>
</p>
<blockquote>
<p>Send bitcoin-dev mailing list submissions to<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a></p>
<p>To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
<a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev-request@lists.linuxfoundation.org</a></p>
<p>You can reach the person managing the list at<br>
<a href=3D"mailto:bitcoin-dev-owner@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev-owner@lists.linuxfoundation.org</a></p>
<p>When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of bitcoin-dev digest...&quot;</p>
<p>Today&#39;s Topics:</p>
<p>1. ANYPREVOUT in place of CTV (darosior)</p>
<p>----------------------------------------------------------------------</=
p>
<p>Message: 1<br>
Date: Fri, 22 Apr 2022 11:11:41 +0000<br>
From: darosior <a href=3D"mailto:darosior@protonmail.com" target=3D"_blank"=
>darosior@protonmail.com</a></p>
<p>To: Bitcoin Protocol Discussion<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a></p>
<p>Subject: [bitcoin-dev] ANYPREVOUT in place of CTV<br>
Message-ID:<br>
<a href=3D"mailto:p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP=
7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=3D@protonmail.com" targe=
t=3D"_blank">p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAP=
s-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=3D@protonmail.com</a></p>
<p>Content-Type: text/plain; charset=3Dutf-8</p>
<p>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.</p>
<p>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=
&#39;m wrong) more widely accepted than<br>
CTV&#39;s.</p>
<p>SIGHASH_ANYPREVOUTANYSCRIPT, if its &quot;ANYONECANPAY&quot; behaviour i=
s made 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.</p>
<p>CTV advocates have been presenting vaults as the flagship usecase. Altho=
ugh 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.</p>
<p>If after some time all of us who are currently dubious about CTV&#39;s s=
tated 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. In<br>
the meantime others will have been able to deploy new applications leveragi=
ng ANYPREVOUT (Eltoo, blind<br>
statechains, etc..[1]).</p>
<p>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) 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.</p>
<p>[0] That is, to not commit to the other inputs of the transaction (via <=
code>sha_sequences</code> and maybe also<br>
<code>sha_amounts</code>). Cf <a href=3D"https://github.com/bitcoin/bips/bl=
ob/master/bip-0118.mediawiki#signature-message" target=3D"_blank">https://g=
ithub.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message</a>=
.</p>
<p>[1] <a href=3D"https://anyprevout.xyz/" target=3D"_blank">https://anypre=
vout.xyz/</a> &quot;Use Cases&quot; section</p>
<p>------------------------------</p>
<p>Subject: Digest Footer</p>
<p>_______________________________________________<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" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a></p>
<p>------------------------------</p>
<p>End of bitcoin-dev Digest, Vol 83, Issue 40<br>
*******************************************</p>
</blockquote></div>_______________________________________________<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></div>

--0000000000002e7eb405dd7aa3b3--