summaryrefslogtreecommitdiff
path: root/3c/28fe081f7863f06c8ecb48a0d7e517062f5c57
diff options
context:
space:
mode:
authorAnthony Towns <aj@erisian.com.au>2022-04-20 12:31:07 +1000
committerbitcoindev <bitcoindev@gnusha.org>2022-04-20 02:31:18 +0000
commit9b4d4467693d4d33eb0c12d1a03ca1421779cf07 (patch)
tree317c2cbb344d9ffaf9fdd00c97a5eebc5698eb55 /3c/28fe081f7863f06c8ecb48a0d7e517062f5c57
parentbe1625c03d230d924dd0e4f637ddf30482aff0cf (diff)
downloadpi-bitcoindev-9b4d4467693d4d33eb0c12d1a03ca1421779cf07.tar.gz
pi-bitcoindev-9b4d4467693d4d33eb0c12d1a03ca1421779cf07.zip
Re: [bitcoin-dev] CTV Signet Parameters
Diffstat (limited to '3c/28fe081f7863f06c8ecb48a0d7e517062f5c57')
-rw-r--r--3c/28fe081f7863f06c8ecb48a0d7e517062f5c57135
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
+
+