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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id C1DDAC007A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 00:28:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 908F241C4A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 00:28:51 +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 smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id FvmW6MY26sjm
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 00:28:50 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 2BC8E41B2E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 00:28:49 +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 1nhhAC-0004w6-Sz; Fri, 22 Apr 2022 10:28:46 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 22 Apr 2022 10:28:40 +1000
Date: Fri, 22 Apr 2022 10:28:40 +1000
From: Anthony Towns <aj@erisian.com.au>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220422002840.GB5616@erisian.com.au>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -13
X-Spam-Bar: -
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: Fri, 22 Apr 2022 00:28:51 -0000
On Wed, Apr 20, 2022 at 03:04:53PM -1000, David A. Harding via bitcoin-dev wrote:
> The main criticisms I'm aware of against CTV seem to be along the following
> lines: [...]
> Could those concerns be mitigated by making CTV an automatically reverting
> consensus change with an option to renew? [...]
Buck O Perley suggested that "Many of the use cases that people
are excited to use CTV for ([5], [6]) are very long term in nature
and targeted for long term store of value in contrast to medium of
exchange."
But, if true, that's presumably incompatible with any sort of sunset
that's less than many decades away, so doesn't seem much better than
just having it be available on a signet?
[5] https://github.com/kanzure/python-vaults/blob/master/vaults/bip119_ctv.py
[6] https://github.com/jamesob/simple-ctv-vault
If sunsetting were a good idea, one way to think about implementing it
might be to code it as:
if (DeploymentActiveAfter(pindexPrev, params, FOO) &&
!DeploymentActiveAfter(pindexPrev, params, FOO_SUNSET))
{
EnforceFoo();
}
That is to have sunsetting the feature be its own soft-fork with
pre-declared parameters that are included in the original activation
proposal. That way you don't have to have a second process debate about
how to go about (not) sunsetting the rules, just one on the merits of
whether sunsetting is worth doing or not.
Cheers,
aj
|
