path: root/51/c014390731164814c1f06599c4434b2a7d87fb

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 829F6C002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Apr 2022 17:05:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 717BF41936
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Apr 2022 17:05:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level: 
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
 HTML_MESSAGE=0.001, 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 5_c9DTUuFLQr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Apr 2022 17:05:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com
 [IPv6:2607:f8b0:4864:20::d2c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id E93A741934
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Apr 2022 17:05:48 +0000 (UTC)
Received: by mail-io1-xd2c.google.com with SMTP id o127so2503712iof.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Apr 2022 10:05:48 -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=xJiDpCK4aaTgWqHsnfUPnUhGwprGqdVHJVXsHHUJYaI=;
 b=mAbqXNShUYuOx1Yr7h92R8jVcN7dAzajzzamlua5Jc2QJueThYfq8W3AXHMj6zbj8y
 shI820EPtcAxPNYcUPpn6tgN4Yp7IHC+Sr0FrvV3eNRJ8uqZrcVSALj13NP6nH2MaF0R
 /Yx0cAC8sysWNt3COb1cSIuigRCrhzGKoPq3o=
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=xJiDpCK4aaTgWqHsnfUPnUhGwprGqdVHJVXsHHUJYaI=;
 b=WAbsswL/GkLp1ExQdNkDDi+ELtHFY8uy5Jv/Qcs8at0UvHtiUhvZVPBLasixxxb4iA
 uJv62Shc0+JYMcQ5xCOVhxY56xPwvRQ2sMkIeic646gvdg9Ea6k7m3bY6aOR0voGxzlE
 Lz4lGTt/DWlXhl+T/W2FgjBWtnkaI8X7JjT4rZwGX+xxJ4mmugdLgS7KFuNXSKx1jkL8
 RHyTtiSOHS/det6Lb79JEP2+pCIcef6J37oVluZ+EpnMHAR0c6Pb0+1ikwWtJJ0yWiEd
 tTrtbVJh7dh/36BXJJUEGthRE0vFDfLAdR+bbwEsetOrOUjv20Fm3i0siLyz7GMq4If6
 iIug==
X-Gm-Message-State: AOAM533rR4OpOtSSIa/JPmzsTwrXOq91BAUAyBqxw41Roet0I2UTGQJR
 dBcjMlgp0Gc7WbR5S6IHrx6gZ3ikqRb7fw+HBJSdpiprGWLsnX2R
X-Google-Smtp-Source: ABdhPJz12mAbySWlUx5l5kMi1IPe7Yv2KxEla7WOekKwty4OJNuGv7kYLb4cG4js1wbFKxZlOxYGP7rqBaWD/t1o98o=
X-Received: by 2002:a05:6602:29d2:b0:64c:753c:c490 with SMTP id
 z18-20020a05660229d200b0064c753cc490mr9817297ioq.90.1650474347510; Wed, 20
 Apr 2022 10:05:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhhv2zN3fjzFS1KRoKKZTJi_RUSHCm_FS7WWfazudVVVvg@mail.gmail.com>
 <20220420023107.GA6061@erisian.com.au>
In-Reply-To: <20220420023107.GA6061@erisian.com.au>
From: Nadav Ivgi <nadav@shesek.info>
Date: Wed, 20 Apr 2022 20:05:36 +0300
Message-ID: <CAGXD5f3QmZvj0okeyNouGLRmBxJr_NyxOhJ9QfkegLnw=HKUbw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000031d49905dd190117"
X-Mailman-Approved-At: Wed, 20 Apr 2022 17:22:45 +0000
Subject: Re: [bitcoin-dev] CTV Signet Parameters
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: Wed, 20 Apr 2022 17:05:50 -0000

--00000000000031d49905dd190117
Content-Type: text/plain; charset="UTF-8"

> I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte hash
on the stack evaluate as true?

Not with Taproot's CLEANSTACK rule. It can make sense to always use `DROP
OP_1` even outside of Taproot, just to keep things consistent and to avoid
potential errors when switching from non-Taproot to Taproot. FWIW that's
what I found myself doing when playing with CTV in P2WSH

On Wed, Apr 20, 2022 at 5:31 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev
> wrote:
> > AJ Wrote (in another thread):
> > >   I'd much rather see some real
> > >   third-party experimentation *somewhere* public first, and Jeremy's
> CTV
> > >   signet being completely empty seems like a bad sign to me.
>
> There's now been some 2,200 txs on CTV signet, of which (if I haven't
> missed anything) 317 have been CTV spends:
>
>  - none have been bare CTV (ie, CTV in scriptPubKey directly, not via
>    p2sh/p2wsh/taproot)
>
>  - none have been via p2sh
>
>  - 3 have been via taproot:
>
> https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b2291ca539722a168e8f6b68143b8c157bee20
>
> https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87724ccdad91fa710264206bb87ae1314c796
>
> https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b826213706c216b930aff194f1fb2fca045f7f11
>
>    The first two of these had alternative merkle paths, the last didn't.
>
>  - 314 have been via p2wsh
>
> https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e
>    (don't think there's any meaningfully different examples?)
>
> As far as I can see, all the scripts take the form:
>
>   [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]
>
> (I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte
> hash on the stack evaluate as true? I guess that means everyone's using
> sapio to construct the txs?)
>
> I don't think there's any demos of jamesob's simple-ctv-vault [0], which
> I think uses a p2wsh of "IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx CTV
> ENDIF", rather than taproot branches.
>
> [0] https://github.com/jamesob/simple-ctv-vault
>
> Likewise I don't think there's any examples of "this CTV immediately;
> or if fees are too high, this other CTV that pays more fees after X
> days", though potentially they could be hidden in the untaken taproot
> merkle branches.
>
> I don't think there's any examples of two CTV outputs being combined
> and spent in a single transaction.
>
> I don't see any txs with nSequence set meaningfully; though most (all?)
> of the CTV spends seem to set nSequence to 0x00400000 which I think
> doesn't have a different effect from 0xfffffffe?
>
> That looks to me like there's still not much practical (vs theoretical)
> exploration of CTV going on; but perhaps it's an indication that CTV
> could be substantially simplified and still get all the benefits that
> people are particularly eager for.
>
> > I am unsure that "learning in public" is required --
>
> For a consensus system, part of the learning is "this doesn't seem that
> interesting to me; is it actually valuable enough to others that the
> change is worth the risk it imposes on me?" and that's not something
> you can do purely in private.
>
> One challenge with building a soft fork is that people don't want to
> commit to spending time building something that relies on consensus
> features and run the risk that they might never get deployed. But the
> reverse of that is also a concern: you don't want to deploy consensus
> changes and run the risk that they won't actually turn out to be useful.
>
> Or, perhaps, to "meme-ify" it -- part of the "proof of work" for deploying
> a consensus change is actually proving that it's going to be useful.
> Like sha256 hashing, that does require real work, and it might turn out
> to be wasteful.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>&gt; I didn&#39;t think DROP/1 is necessary here? Doe=
sn&#39;t leaving the 32 byte hash on the stack evaluate as true?</div><div>=
<br></div><div>Not with Taproot&#39;s CLEANSTACK rule. It can make sense to=
 always use `DROP OP_1` even outside of Taproot, just to keep things consis=
tent and to avoid potential errors when switching from non-Taproot to Tapro=
ot. FWIW that&#39;s what I found myself doing when playing with CTV in P2WS=
H </div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Wed, Apr 20, 2022 at 5:31 AM Anthony Towns via bitcoin-dev &lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin vi=
a bitcoin-dev wrote:<br>
&gt; AJ Wrote (in another thread):<br>
&gt; &gt;=C2=A0 =C2=A0I&#39;d much rather see some real<br>
&gt; &gt;=C2=A0 =C2=A0third-party experimentation *somewhere* public first,=
 and Jeremy&#39;s CTV<br>
&gt; &gt;=C2=A0 =C2=A0signet being completely empty seems like a bad sign t=
o me. <br>
<br>
There&#39;s now been some 2,200 txs on CTV signet, of which (if I haven&#39=
;t<br>
missed anything) 317 have been CTV spends:<br>
<br>
=C2=A0- none have been bare CTV (ie, CTV in scriptPubKey directly, not via<=
br>
=C2=A0 =C2=A0p2sh/p2wsh/taproot)<br>
<br>
=C2=A0- none have been via p2sh<br>
<br>
=C2=A0- 3 have been via taproot:<br>
=C2=A0 =C2=A0 <a href=3D"https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc=
8da597f843b2291ca539722a168e8f6b68143b8c157bee20" rel=3D"noreferrer" target=
=3D"_blank">https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b22=
91ca539722a168e8f6b68143b8c157bee20</a><br>
=C2=A0 =C2=A0 <a href=3D"https://explorer.ctvsignet.com/tx/7e4ade977db94117=
f2d7a71541d87724ccdad91fa710264206bb87ae1314c796" rel=3D"noreferrer" target=
=3D"_blank">https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87=
724ccdad91fa710264206bb87ae1314c796</a><br>
=C2=A0 =C2=A0 <a href=3D"https://explorer.ctvsignet.com/tx/e05d828bf716effc=
65b00ae8b826213706c216b930aff194f1fb2fca045f7f11" rel=3D"noreferrer" target=
=3D"_blank">https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b8262=
13706c216b930aff194f1fb2fca045f7f11</a><br>
<br>
=C2=A0 =C2=A0The first two of these had alternative merkle paths, the last =
didn&#39;t.<br>
<br>
=C2=A0- 314 have been via p2wsh<br>
=C2=A0 =C2=A0 <a href=3D"https://explorer.ctvsignet.com/tx/62292138c2f55713=
c3c161bd7ab36c7212362b648cf3f054315853a081f5808e" rel=3D"noreferrer" target=
=3D"_blank">https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36=
c7212362b648cf3f054315853a081f5808e</a><br>
=C2=A0 =C2=A0(don&#39;t think there&#39;s any meaningfully different exampl=
es?)<br>
<br>
As far as I can see, all the scripts take the form:<br>
<br>
=C2=A0 [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]<br>
<br>
(I didn&#39;t think DROP/1 is necessary here? Doesn&#39;t leaving the 32 by=
te<br>
hash on the stack evaluate as true? I guess that means everyone&#39;s using=
<br>
sapio to construct the txs?)<br>
<br>
I don&#39;t think there&#39;s any demos of jamesob&#39;s simple-ctv-vault [=
0], which<br>
I think uses a p2wsh of &quot;IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx=
 CTV<br>
ENDIF&quot;, rather than taproot branches.<br>
<br>
[0] <a href=3D"https://github.com/jamesob/simple-ctv-vault" rel=3D"noreferr=
er" target=3D"_blank">https://github.com/jamesob/simple-ctv-vault</a><br>
<br>
Likewise I don&#39;t think there&#39;s any examples of &quot;this CTV immed=
iately;<br>
or if fees are too high, this other CTV that pays more fees after X<br>
days&quot;, though potentially they could be hidden in the untaken taproot<=
br>
merkle branches.<br>
<br>
I don&#39;t think there&#39;s any examples of two CTV outputs being combine=
d<br>
and spent in a single transaction.<br>
<br>
I don&#39;t see any txs with nSequence set meaningfully; though most (all?)=
<br>
of the CTV spends seem to set nSequence to 0x00400000 which I think<br>
doesn&#39;t have a different effect from 0xfffffffe?<br>
<br>
That looks to me like there&#39;s still not much practical (vs theoretical)=
<br>
exploration of CTV going on; but perhaps it&#39;s an indication that CTV<br=
>
could be substantially simplified and still get all the benefits that<br>
people are particularly eager for.<br>
<br>
&gt; I am unsure that &quot;learning in public&quot; is required --<br>
<br>
For a consensus system, part of the learning is &quot;this doesn&#39;t seem=
 that<br>
interesting to me; is it actually valuable enough to others that the<br>
change is worth the risk it imposes on me?&quot; and that&#39;s not somethi=
ng<br>
you can do purely in private.<br>
<br>
One challenge with building a soft fork is that people don&#39;t want to<br=
>
commit to spending time building something that relies on consensus<br>
features and run the risk that they might never get deployed. But the<br>
reverse of that is also a concern: you don&#39;t want to deploy consensus<b=
r>
changes and run the risk that they won&#39;t actually turn out to be useful=
.<br>
<br>
Or, perhaps, to &quot;meme-ify&quot; it -- part of the &quot;proof of work&=
quot; for deploying<br>
a consensus change is actually proving that it&#39;s going to be useful.<br=
>
Like sha256 hashing, that does require real work, and it might turn out<br>
to be wasteful.<br>
<br>
Cheers,<br>
aj<br>
<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>

--00000000000031d49905dd190117--