path: root/4d/813ce47166dcf2ee5c80e0736781ffa796f84e

Return-Path: <nadav@shesek.info>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A96A1C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 16:35:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 96DCC4022C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 16:35:30 +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: smtp2.osuosl.org (amavisd-new); dkim=neutral
 reason="invalid (public key: not available)" header.d=shesek.info
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3TUQagfic7W3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 16:35:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com
 [IPv6:2607:f8b0:4864:20::d35])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 76B984011F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 16:35:29 +0000 (UTC)
Received: by mail-io1-xd35.google.com with SMTP id p62so16502540iod.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 09:35:29 -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=WXsXQ2toSpkyzMCX7A7614Pwizn6UIzY4G2JPkt0bX0=;
 b=TkdloDOUsIpJH5op2JAzEiSlASmNqorXTfmiMDObIKTbv6QAf2rHCdQaiC7VSNS+cz
 uSuQnetktNkoCWTgJbLg+JsZ2fXLHCD2TuJohvti34Vv3nFRDnHb+Db7B2829zn04CXX
 ECKzI0Mt8RyTCeedLsquAEfRAgwUC505p1W70=
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=WXsXQ2toSpkyzMCX7A7614Pwizn6UIzY4G2JPkt0bX0=;
 b=jGjamZyJC1oKGrxMgTWjPHm4FaPLpxGfKCQzVDbthZUe0PNKvR5emAu8sPn98OnPDi
 t8/eJLCA7uzMm1Dc9RlBsgWQJ+9jUkegK/qY6Argo/WWn4d6DMWiUkTDSK4F/xGA/T+V
 K5hSc1dGiX4PwgLl2cQ4FdQDXdxhxE869qCPdR6nmDYtF4kvdAg0a1+N/N25qHSJeZjO
 83BW6AIvBrcHfdgF+TEsJnEX8e1thaTcvUGIc0o4YPqP+qsrVrZ68muNr3WD2+/tzeG3
 OHb8yuFDHjzbyaYf62dLDu1Zheu+XbQxGTigp5+o3S2DYQXpqiIUHJdfQx6OD9qBNMuQ
 wRRw==
X-Gm-Message-State: AOAM531bYic7wJy2+HAtLtGIshinQC5eHnp53DssEowI4YjV0TMRFZ7E
 UfC9r2HfeVQS4OBQSSCIjU30JsNMNBRYUCa/2LzC8BT+uNFjobTP
X-Google-Smtp-Source: ABdhPJz4ezCtRwwXFNpWm3R2Wf2Zp7apQQGqoACoCxLAw1JXGNcEAy6NCz8iaDBALzKQQXqa9RP8OmQgOdAH+HIP3IY=
X-Received: by 2002:a05:6602:2a42:b0:652:8e2d:e4b7 with SMTP id
 k2-20020a0566022a4200b006528e2de4b7mr7049226iov.142.1650904528512; Mon, 25
 Apr 2022 09:35:28 -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: Mon, 25 Apr 2022 19:35:17 +0300
Message-ID: <CAGXD5f2B7DJndj-3hGt_7mcbsR4qRtQE4zexuPHiSOi5Ba07ig@mail.gmail.com>
To: darosior <darosior@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000fafae705dd7d2918"
X-Mailman-Approved-At: Mon, 25 Apr 2022 16:51:20 +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: Mon, 25 Apr 2022 16:35:30 -0000

--000000000000fafae705dd7d2918
Content-Type: text/plain; charset="UTF-8"

darosior via bitcoin-dev wrote:

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

Some potential vault users looking to store funds for long time periods
(say of decades) might have quantumphobia and prefer to avoid Taproot for
that reason.

One of the arguments presented for not using pubkey hashes in Taproot is
that quantumphobic people could choose to continue using non-Taproot
outputs. Making a feature that's targeted for long-term cold-storage vaults
available on Taproot only might be less ideal in that view.

Cheers
shesek

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
>

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

<div dir=3D"ltr"><div dir=3D"ltr">darosior via bitcoin-dev wrote:</div><div=
 dir=3D"ltr"><br></div><div dir=3D"ltr">&gt; CTV advocates have been presen=
ting vaults as the flagship usecase. Although as someone who&#39;ve been tr=
ying to<br>
&gt; implement practical vaults for the past 2 years i doubt CTV is necessa=
ry nor sufficient for this (but still<br>
&gt; useful!), using APO-AS covers it. And it&#39;s not a couple dozen more=
 virtual bytes that are going to matter for<br>
&gt; a potential vault user.</div><div dir=3D"ltr"><br></div><div>Some pote=
ntial vault users looking to store funds for long time periods (say of deca=
des) might have quantumphobia and prefer to avoid Taproot for that reason.<=
/div><div><br></div><div>One of the arguments presented for not using pubke=
y hashes in Taproot is that quantumphobic people could choose to continue u=
sing non-Taproot outputs. Making a feature that&#39;s targeted for long-ter=
m cold-storage vaults available on Taproot only might be less ideal in that=
 view.</div><div><br></div><div>Cheers<br></div><div>shesek<br></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:bi=
tcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I=
 would like to know people&#39;s sentiment about doing (a very slightly twe=
aked 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>

--000000000000fafae705dd7d2918--