1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
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
|
