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: <dave@dtrt.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9D21AC007A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 01:44:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7D9D3818BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 01:44:44 +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 oRbnZ94Hzxd6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 01:44:43 +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 D0540818A2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 01:44:43 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 993682800078;
Thu, 21 Apr 2022 18:44:41 -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;
Thu, 21 Apr 2022 18:44:41 -0700 (PDT)
MIME-Version: 1.0
Date: Thu, 21 Apr 2022 15:44:41 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Anthony Towns <aj@erisian.com.au>
In-Reply-To: <20220422002840.GB5616@erisian.com.au>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
<20220422002840.GB5616@erisian.com.au>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <c62c913ac4e36182f719ddb754a0f754@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 ef0.62620889.d3c6.0
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Fri, 22 Apr 2022 01:44:44 -0000
On 21.04.2022 14:28, Anthony Towns wrote:
> But, if [it's true that "many [...] use cases [...] to use CTV for
> are very long term in nature"], 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?
I fully acknowledge that a temporary test can't fully replicate a
permanent condition. That said, if people truly believe CTV vaults will
significantly enhance their security, wouldn't it be worth using them
for most of the deployment? Users would receive both years of added
security and the opportunity to convince other Bitcoiners to make CTV
permanent by demonstrating real-world usage.
> 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();
> }
Defining at the outset how we'll signal years later if we want to keep
the rules seems intelligent to me.
Thanks!,
-Dave
|
