Re: [bitcoin-dev] CTV Signet Parameters

From: Nadav Ivgi <nadav@shesek•info>
To: Anthony Towns <aj@erisian•com.au>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV Signet Parameters
Date: Wed, 20 Apr 2022 20:05:36 +0300	[thread overview]
Message-ID: <CAGXD5f3QmZvj0okeyNouGLRmBxJr_NyxOhJ9QfkegLnw=HKUbw@mail.gmail.com> (raw)
In-Reply-To: <20220420023107.GA6061@erisian.com.au>

[-- Attachment #1: Type: text/plain, Size: 4110 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5805 bytes --]