Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 829F6C002C for ; 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 ; 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 ; 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 ; Wed, 20 Apr 2022 17:05:48 +0000 (UTC) Received: by mail-io1-xd2c.google.com with SMTP id o127so2503712iof.12 for ; 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: <20220420023107.GA6061@erisian.com.au> In-Reply-To: <20220420023107.GA6061@erisian.com.au> From: Nadav Ivgi Date: Wed, 20 Apr 2022 20:05:36 +0300 Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
> I didn't think DROP/1 is necessary here? Doe= sn'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 consis= tent and to avoid potential errors when switching from non-Taproot to Tapro= ot. FWIW that's what I found myself doing when playing with CTV in P2WS= H

On Wed, Apr 20, 2022 at 5:31 AM Anthony Towns via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l= inuxfoundation.org> wrote:
On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin vi= a bitcoin-dev wrote:
> AJ Wrote (in another thread):
> >=C2=A0 =C2=A0I'd much rather see some real
> >=C2=A0 =C2=A0third-party experimentation *somewhere* public first,= and Jeremy's CTV
> >=C2=A0 =C2=A0signet being completely empty seems like a bad sign t= o 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:

=C2=A0- none have been bare CTV (ie, CTV in scriptPubKey directly, not via<= br> =C2=A0 =C2=A0p2sh/p2wsh/taproot)

=C2=A0- none have been via p2sh

=C2=A0- 3 have been via taproot:
=C2=A0 =C2=A0 https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b22= 91ca539722a168e8f6b68143b8c157bee20
=C2=A0 =C2=A0 https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87= 724ccdad91fa710264206bb87ae1314c796
=C2=A0 =C2=A0 https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b8262= 13706c216b930aff194f1fb2fca045f7f11

=C2=A0 =C2=A0The first two of these had alternative merkle paths, the last = didn't.

=C2=A0- 314 have been via p2wsh
=C2=A0 =C2=A0 https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36= c7212362b648cf3f054315853a081f5808e
=C2=A0 =C2=A0(don't think there's any meaningfully different exampl= es?)

As far as I can see, all the scripts take the form:

=C2=A0 [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]

(I didn't think DROP/1 is necessary here? Doesn't leaving the 32 by= te
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 immed= iately;
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<= br> merkle branches.

I don't think there's any examples of two CTV outputs being combine= d
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 somethi= ng
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&= quot; 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/mail= man/listinfo/bitcoin-dev
--00000000000031d49905dd190117--