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
|
Return-Path: <luke@dashjr.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6AEB5C002C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 05:57:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 5215A610AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 05:57:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -3.517
X-Spam-Level:
X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
NICE_REPLY_A=-0.117, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dashjr.org
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TMKRCoW1cgiF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 05:57:00 +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 smtp3.osuosl.org (Postfix) with ESMTP id DDA4D60B88
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 05:56:59 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.151.133.18])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 300BE38A1C93;
Thu, 21 Apr 2022 05:56:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1650520616; bh=LZWwpG7gzpWTIFPMFjfRCCDJ92d60gQXevqbvTc0OUY=;
h=From:To:Subject:Date:Cc:References:In-Reply-To;
b=pJJhx+PTS2M9kB8XJWrM57n9eOgyq/+RlyQszufuN5JiJGqQ3GNXeT0xntFDQAZkt
hZoAm3yRWd6/SVgzFPPirTxLVHWHgjSOydv0swdzbx2L1DKa9Rq0/JsOBmZ+5/2Kap
2FXWrdcVT4gY1pkbU5n+f5kcPnQ9o/8yVa5Yslrg=
From: Luke Dashjr <luke@dashjr.org>
To: alicexbt <alicexbt@protonmail.com>
Date: Thu, 21 Apr 2022 05:56:54 +0000
User-Agent: KMail/1.9.10
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
<202204210205.47678.luke@dashjr.org>
<R95icCQeG6oNu4uNppxVTceaMmZzOQhUD40HhOXkuQCOzUY_P5uM1F1AGBejdydrSjl4RYE538VWiDHeGx3YcaS0S-z_q9v5UaCK_Y4b5TE=@protonmail.com>
In-Reply-To: <R95icCQeG6oNu4uNppxVTceaMmZzOQhUD40HhOXkuQCOzUY_P5uM1F1AGBejdydrSjl4RYE538VWiDHeGx3YcaS0S-z_q9v5UaCK_Y4b5TE=@protonmail.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202204210556.54781.luke@dashjr.org>
Cc: 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: Thu, 21 Apr 2022 05:57:02 -0000
On Thursday 21 April 2022 03:10:02 alicexbt wrote:
> @DavidHarding
>
> Interesting proposal to revert consensus changes. Is it possible to do this
> for soft forks that are already activated?
Generally, no. Reverting a softfork without a built-in expiry would be a
hardfork.
> Example: Some users are not okay with witness discount in segwit
> transactions
>
> https://nitter.net/giacomozucco/status/1513614380121927682
While reverting Segwit wouldn't be possible, it IS entirely possible to do an
additional softfork to either weigh witness data at the full 4 WU/Byte rate
(same as other data), or to reduce the total weight limit so as to extend the
witness discount to non-segwit transactions (so scriptSig is similarly
discounted).
> @LukeDashjr
>
> > 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).
>
> Agree. UASF client compatible with this speedy trial release for BIP 119
> could be a better way to activate CTV. Users can decide if they prefer
> mining pools to make the decision for them or they want to enforce it
> irrespective of how many mining pools signal for it. I haven't seen any
> arguments against CTV from mining pools yet.
We had that for Taproot, and now certain people are trying to say Speedy Trial
activated Taproot rather than the BIP8 client, and otherwise creating
confusion and ambiguity.
Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
variant which has no purpose other than to try to sabotage parallel UASF
efforts.
At this point, it is probably better for any Speedy Trial attempts to be
rejected by the community and fail outright. Perhaps even preparing a real
counter-softfork to invalidate blocks signalling for it.
Luke
|
