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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Return-Path: <dave@dtrt.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5EAC6C002C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 01:04:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 3F38D83077
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 01:04:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=no 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 7LGf4Z9MJyE3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 01:04:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp1.osuosl.org (Postfix) with ESMTPS id 8191D82F6F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 01:04:55 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 1DDFA2801D0B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Apr 2022 18:04:54 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Apr 2022 18:04:53 -0700 (PDT)
MIME-Version: 1.0
Date: Wed, 20 Apr 2022 15:04:53 -1000
From: "David A. Harding" <dave@dtrt.org>
To: bitcoin-dev@lists.linuxfoundation.org
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 1201.6260adb5.a05fa.0
Subject: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
e.g. for CTV
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: Thu, 21 Apr 2022 01:04:56 -0000
Hi all,
The main criticisms I'm aware of against CTV seem to be along the
following lines:
1. Usage, either:
a. It won't receive significant real-world usage, or
b. It will be used but we'll end up using something better later
2. An unused CTV will need to be supported forever, creating extra
maintenance
burden, increasing security surface, and making it harder to evaluate
later
consensus change proposals due to their interactions with CTV
Could those concerns be mitigated by making CTV an automatically
reverting
consensus change with an option to renew? E.g., redefining OP_NOP4 as
OP_CTV
for five years from BIP119's activation date and then reverting to
OP_NOP4.
If, prior to the end of those five years, a second soft fork was
activated, it
could continue enforcing the CTV rules either for another five years or
permanently.
This would be similar in nature to the soft fork described in BIP50
where the
maximum block size was temporarily reduced to address the BDB locks
issue and
then allowed to return to its original value. In Script terms, any use
of
OP_CTV would effectively be:
OP_IF
<arguments> OP_CTV
OP_ELSE
<5 years after activation> OP_CLTV
OP_ENDIF
As long as we are absolutely convinced CTV will have no negative effects
on the
holders or receivers of non-CTV coins, I think an automatically
reverting soft
fork gives us some ability to experiment with new features without
committing
ourselves to live with them forever.
The main downsides I can see are:
1. It creates a big footgun. Anyone who uses CTV without adequately
preparing for
the reversion could easily lose their money.
2. Miners would be incentivized to censor spends of the reverting
opcode near its reversion date. E.g., if Alice receives 100 bitcoins
to a
script secured only by OP_CTV and attempts to spend them the day
before it
becomes OP_NOP4, miners might prefer to skip confirming that
transaction even
if it pays a high feerate in favor of spending her 100 bitcoins to
themselves
the next day after reversion.
The degree to which this is an issue will depend on the diversity of
hashrate and the willingness of any large percentage of hashrate to
deliberately reorg the chain to remove confirmed transactions. This
could be
mitigated by having OP_CTV change to OP_RETURN, destroying any
unspent CTV-only
coins so that any censoring miners only benefited from the (hopefully
slight)
decrease in bitcoin currency supply.
3. A bias towards keeping the change. Even if it turned out very few
people
really used CTV, I think there would be a bias at the end of five
years towards
"why not just keep it".
4. The drama doesn't end. Activating CTV now, or decisively not
activating it,
may bring to an end our frequent discussions about it (though I
wouldn't
count on that). An automatically reverting soft fork would probably
guarantee we'll have further consensus-level discussions about CTV in
the
future.
Thanks for reading. I'm curious to hear y'alls thoughts,
-Dave
|
