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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <luke@dashjr.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4F40CC002C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 02:05:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 457E34015A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 02:05:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dashjr.org
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 0KqHgL1ld9C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 02:05:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1])
by smtp2.osuosl.org (Postfix) with ESMTP id D214D4013B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 02:05:50 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.151.133.18])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id C525538A189E;
Thu, 21 Apr 2022 02:05:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1650506749; bh=j07vl4mIXnZukqkKv2dVkgJKpXF2dFfvlNOTZv5raM4=;
h=From:To:Subject:Date:References:In-Reply-To;
b=eGFe9xrqC6eN0BmLtqvi/1YLMyNGII2RJ/OWR0RP8GNpA4m7Z4N51DrALxgpSBMZH
Qqs5bWc4REnCViOPMJY0CgprF5PYrXJriEqgyOyZ0Jvv9H1BX0GvSi3oFfALMTbHa+
D13t4Pgufu+PzXPR4oIE7H1k3KyuYZAIW/ZKKhsw=
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, "David A. Harding" <dave@dtrt.org>
Date: Thu, 21 Apr 2022 02:05:47 +0000
User-Agent: KMail/1.9.10
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202204210205.47678.luke@dashjr.org>
Subject: Re: [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 02:05:52 -0000
1-2 can be mitigated to some extent by encoding an expiry height in the
address (and pubkey?), and honouring CTV for UTXOs during the active period.
It might take longer to remove CTV code post-deactivation, but that's simply
a tradeoff to consider.
The bigger issue with CTV is the miner-decision route. Either CTV has
community support, or it doesn't. If it does, miners shouldn't have the
ability to veto it. If it doesn't, miners shouldn't have the ability to
activate it (making it a 51% attack more than a softfork).
On Thursday 21 April 2022 01:04:53 David A. Harding via bitcoin-dev wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
