diff options
author | Anthony Towns <aj@erisian.com.au> | 2022-04-20 12:31:07 +1000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-20 02:31:18 +0000 |
commit | 9b4d4467693d4d33eb0c12d1a03ca1421779cf07 (patch) | |
tree | 317c2cbb344d9ffaf9fdd00c97a5eebc5698eb55 /3c/28fe081f7863f06c8ecb48a0d7e517062f5c57 | |
parent | be1625c03d230d924dd0e4f637ddf30482aff0cf (diff) | |
download | pi-bitcoindev-9b4d4467693d4d33eb0c12d1a03ca1421779cf07.tar.gz pi-bitcoindev-9b4d4467693d4d33eb0c12d1a03ca1421779cf07.zip |
Re: [bitcoin-dev] CTV Signet Parameters
Diffstat (limited to '3c/28fe081f7863f06c8ecb48a0d7e517062f5c57')
-rw-r--r-- | 3c/28fe081f7863f06c8ecb48a0d7e517062f5c57 | 135 |
1 files changed, 135 insertions, 0 deletions
diff --git a/3c/28fe081f7863f06c8ecb48a0d7e517062f5c57 b/3c/28fe081f7863f06c8ecb48a0d7e517062f5c57 new file mode 100644 index 000000000..c465a8a82 --- /dev/null +++ b/3c/28fe081f7863f06c8ecb48a0d7e517062f5c57 @@ -0,0 +1,135 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id DA959C002C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 20 Apr 2022 02:31:18 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id B3F1483F25 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 20 Apr 2022 02:31:18 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.901 +X-Spam-Level: +X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, + UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id PqptEjaQRVkW + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 20 Apr 2022 02:31:17 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 823A083F1F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 20 Apr 2022 02:31:17 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) + id 1nh07c-0003JX-J2; Wed, 20 Apr 2022 12:31:14 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Wed, 20 Apr 2022 12:31:07 +1000 +Date: Wed, 20 Apr 2022 12:31:07 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20220420023107.GA6061@erisian.com.au> +References: <CAD5xwhhv2zN3fjzFS1KRoKKZTJi_RUSHCm_FS7WWfazudVVVvg@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <CAD5xwhhv2zN3fjzFS1KRoKKZTJi_RUSHCm_FS7WWfazudVVVvg@mail.gmail.com> +User-Agent: Mutt/1.10.1 (2018-07-13) +X-Spam-Score-int: -18 +X-Spam-Bar: - +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 02:31:19 -0000 + +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 + + |