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
|
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 822C6C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Jun 2021 21:13:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 698B7400C2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Jun 2021 21:13:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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_NONE=-0.0001,
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 4Arzd08hZib6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Jun 2021 21:13:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp2.osuosl.org (Postfix) with ESMTP id DC40E400C1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Jun 2021 21:13:09 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.218])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 8E3E238A00AE;
Sat, 26 Jun 2021 21:13:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1624741987; bh=Vu0vvXsp9h455NrXGDlZBlUWc0Op27IKw36O2gvCtpQ=;
h=From:To:Subject:Date:References:In-Reply-To;
b=jpH8Awn7EYNX3JQNmZnXG4WoUKARq+WG3XktbajZkZPXLhDmCGBU1JZdbl4x5aIMJ
HR2gKv3zEeR0mrEAyNbCto/Ml9JT/Eyx0pAroqzfg3MtJ0aX7QHpzTYRQZjbRbD9Ew
iH7MyI3MibUP1vvgZIzm+4Oif+WoE+VwHDFtweCY=
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Billy Tetrud <billy.tetrud@gmail.com>
Date: Sat, 26 Jun 2021 21:13:04 +0000
User-Agent: KMail/1.9.10
References: <CAGpPWDaq88q6Kd4tziB9G4V74PiXUg=_Nx1M_WK6dG_g3r+ruw@mail.gmail.com>
In-Reply-To: <CAGpPWDaq88q6Kd4tziB9G4V74PiXUg=_Nx1M_WK6dG_g3r+ruw@mail.gmail.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202106262113.05006.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
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: Sat, 26 Jun 2021 21:13:11 -0000
BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
still slow it down.
It also already has the trinary state you seem to be describing (although
perhaps this could be better documented in the BIP): users who oppose the
softfork can and should treat the successful signal (whether MASF or UASF) as
invalid, thereby ensuring they do not follow a chain with the rules in force.
No additional bit is needed, as softforks are coordinated between users, NOT
miners (who have no particular say in them, aside from their role as also
being users). The miner involvement is only out of necessity (to set the bit
in the header, which users coordinate with) and potentially to accelerate
activation by protecting upgrade-lagging users.
Luke
On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
> Given the recent controversy over upgrade mechanisms for the
> non-controversial taproot upgrade, I have been thinking about ways to solve
> the problems that both sides brought up. In short, BIP8 LOT=true proponents
> make the point that lazy miners failing to upgrade in a timely manner slow
> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> proponents make the point that LOT=true can lead to undesirable forks that
> might cause a lot of chaos. I believe both points are essentially correct
> and have created a proposal
> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>
> The proposal uses trinary version signaling rather than binary signaling.
> For any particular prospective soft fork upgrade, this allows for three
> signaling states:
>
> * Actively support the change.
> * Actively oppose the change.
> * Not signaling (neither support or oppose). This is the default state.
>
> Using this additional information, we can release non-contentious upgrades
> much quicker (with a much lower percent of miners signaling support). For
> contentious upgrades, miners who oppose the change are incentivized to
> update their software to a version that can actively signal opposition to
> the change. The more opposition there is, the higher the threshold
> necessary to lock in the upgrade. With the parameters I currently
> recommended in the proposal, this chart shows how much support signaling
> would be necessary given a particular amount of active opposition
> signaling:
>
> [image: thresholdChart.png]
> If literally no one signals opposition, a 60% threshold should be
> relatively safe because it is a supermajority amount that is unlikely to
> change significantly very quickly (ie if 60% of miners support the change
> today, its unlikely that less than a majority of miners would support the
> change a year or two from now), and if no one is signaling opposition,
> chances are that the vast majority of the other 40% would also eventually
> signal support.
>
> This both gives an incentive for "lazy" miners to upgrade if they actually
> oppose the change while at the same time allowing these lazy miners to
> remain lazy without slowing down the soft fork activation much.
>
> I think now is the right time to discuss new soft fork upgrade mechanisms,
> when there are no pressing soft fork upgrades ready to deploy. Waiting
> until we need to deploy a soft fork to discuss this will only delay things
> and cause contention again like it did with taproot.
>
> I'm very curious to know what people think of this mechanism. I would
> appreciate any comments here, or written as github issues on the proposal
> repo itself.
>
> Thanks,
> BT
|
