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
|
Return-Path: <aj@erisian.com.au>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id E0D7CC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 03:20:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id C731186D52
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 03:20:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 2miXhmUx9ISc
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 03:20:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by hemlock.osuosl.org (Postfix) with ESMTPS id A4CE486CD3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 03:20:37 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1irCkp-0001p8-4N; Tue, 14 Jan 2020 13:20:32 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Tue, 14 Jan 2020 13:20:26 +1000
Date: Tue, 14 Jan 2020 13:20:26 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Yosef <asix@disroot.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200114032026.33ft2qsjk72citpr@erisian.com.au>
References: <415e793656ab4326b48d9dc050a85eb8@disroot.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <415e793656ab4326b48d9dc050a85eb8@disroot.org>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Modern Soft Fork Activation
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: Tue, 14 Jan 2020 03:20:39 -0000
On Mon, Jan 13, 2020 at 08:34:24AM +0000, Yosef via bitcoin-dev wrote:
> tl;dr How about 80% ?
The point of having hashpower upgraded is that it means that there's low
liklihood of long chains of blocks that are invalid per the new rules, so
that if you haven't upgraded your node but wait for a few confirmations,
you'll still (with very high liklihood) only see blocks valid per the
new rules.
If you have 80% of miners enforcing the rules, then if someone produces
a block that violates the new rules (but is valid for the old ones),
then you've got a 20% chance of one of the non-enforcing miners getting
the next block, and a 4% chance of non-enforcing miners getting both
the next blocks, giving 3 confirmations to invalid transactions. That
seems a bit high.
3 confirmations isn't unrealistic, eg Coinbase apparently recently
dropped its requirement to that apparently:
https://blog.coinbase.com/announcing-new-confirmation-requirements-4a5504ba8d81
I could maybe see a 90% threshold though?
> 95% can prove difficult to achieve. Some % of negligent miners that forget to upgrade is expected.
Is it? We went from 59% to 54% to 28% to 0% (!!) of blocks not signalling
for segwit during consecutive two-week blocks in the BIP-91/148
period; and from 100% of blocks not signalling for BIP-91 to 99.4%,
48%, 15%, and 11% during consecutive 2.3 day periods targeting an 80%
threshold. Certainly that was a particularly high-stakes period, but
they were both pretty short. For comparison, for CSV, we went from 100%
not signalling to 61%, to 54% to 3.4% in consecutive two-week periods.
> Completing that to 5% is not too difficult for a small malicious minority trying to delay the activation. This is the issue Matt's goal #5 aims to prevent, and while the fallback to BIP-8 helps, BIP-9’s 95% requirement makes it worse by allowing quite a neglected minority to force a dramatic delay. Also note how in such case it would have been better to skip BIP-9 altogether and maybe save 1.5 years.
I don't think you can really skip steps if you need a flag day:
- the first 12 months is for *really seriously* making sure there's no
problems with the proposed upgrade; you can't that because people
might not look for problems until the code's out there and ready for
actual use
- the next 6 months is for updating the software to lock in the flag
day; you can't skip that because it takes time to get new releases out
- the next 24 months is to ensure everyone's upgraded their nodes so
that they won't be at risk of thinking they've received bitcoins when
those coins aren't in compliance with the new rules; and you can't
skip that because if we don't have hashpower reliably enforcing the
rules, *everybody* needs to upgrade, which can take a lot of time.
Times could be tweaked, but the "everyone has to upgrade their node
software" is almost the same constraint that hard forks have, so I think
you want to end up with a long overall lead time any which way. For
comparison, 0.12.1 came out about 45 months ago and 0.13.2 came out
about 36 months ago -- about 0.5% of nodes are running 0.12 or earler,
and about 4.9% of nodes are running 0.13 or earlier, at least per [0],
so the overall timeline of 42 months seems plausible to me...
[0] https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
I think (especially if we attempt BIP-91/BIP-148-style compulsory
signalling again) it's worth also considering the failure case if miners
false-signal: that is they signal support of the new soft-fork rules,
but then don't actually enforce them. If you end up with, say, 15% of
hashpower not upgraded or signalling, 25% of hashpower not upgraded but
signalling so their blocks don't get orphaned, and only 65% of hashpower
upgraded, you have a 1% chance of 5 blocks built on top of a block
that's invalid according to the new rules, giving those transactions 6
confirmations as far as non-upgraded nodes are concerned.
Cheers,
aj
|
