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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Return-Path: <john@johnnewbery.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 63FF9C37
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Aug 2019 15:23:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com
[209.85.210.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 54306786
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Aug 2019 15:23:51 +0000 (UTC)
Received: by mail-ot1-f44.google.com with SMTP id w4so9845568ote.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Aug 2019 08:23:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=johnnewbery-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=FmWCoQYYbRBLxsD0DzeHzqOP4CqRuHqFVOtvF3UooYk=;
b=jPm7qt1+IMIrUxx6B8zSN5/S60eq4BimsdniEcW84DboVBI9RgP1kUF1HUnZs7MLkw
XubdoPxSg6wjrPEpGVp4DEiL5eGq1VfYI+8DNICqMKJFGw1n3iCLmphe1AFT0FstmOzw
EnbuSUOBZu2i2w7vnWq1+MkCHmpTQUqg1VGaEBMzsT91QeczLm+VB/3wnvGJgG2wslcz
EjFpgUSMrVky51PUOSZ4Ts62ASZVe+kGV7VPHGUCLcdYTgkZwcTDWyUoCvVqkAcfql3f
IAN7YZudBKoQ3DrsWv0dQHdIQeZledxR6TkATCdvbAmH2T/FUSjZhnxmjgT8VhXDpx6+
lbwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=FmWCoQYYbRBLxsD0DzeHzqOP4CqRuHqFVOtvF3UooYk=;
b=b0rGbPH3VCzYovbXfqSFuxvzztHlsxkw/Zg98zo73A7pHDxINQTerKZ/AmXHGEUfNk
0eAJpFLiAk0yLRDcMPaqvHD6WjrJsvqxwgZP+NE5mA1fmwHzDTMMrOC73yOgZsnwqYat
q70uEEC/Pwy7PoWZ+nDepPcEbgbqtKBK/Zbdg+LvA8egHoU763AabuoRmziIG2vtrkk+
GXRsBq+Lnm2X2AZu8NdtMN411QpdriKHG9Is4Jb7fe7p3U79hFDuvVtfqGV6zUYpA+Fh
oE7L2hTPWKkxe0eQX1IlguExSeDN5yR9DYKfqBi0DHv7R7BwCPxDVH+VVvPZMf4ShiFl
0Phw==
X-Gm-Message-State: APjAAAXbg3EWEYCkJSCn4OXHrHBpDJT5yBqMtXuw/EqDO/BNzCqBw6tP
i7ZTcGFAUEuoM/Gs55L7UVxE2h6+x1U=
X-Google-Smtp-Source: APXvYqxfCcJODQOXgsfIN7W3OEr/PwsUjjhb1DFhXmSVTlKO2jZyK9Kwkqyf92zMBeo8iqjLyl/rXw==
X-Received: by 2002:a9d:6854:: with SMTP id c20mr1978943oto.120.1565969030093;
Fri, 16 Aug 2019 08:23:50 -0700 (PDT)
Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com.
[209.85.167.172]) by smtp.gmail.com with ESMTPSA id
f197sm1592033oib.20.2019.08.16.08.23.48
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 16 Aug 2019 08:23:49 -0700 (PDT)
Received: by mail-oi1-f172.google.com with SMTP id p124so5059654oig.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Aug 2019 08:23:48 -0700 (PDT)
X-Received: by 2002:aca:ecd6:: with SMTP id k205mr5558855oih.159.1565969028147;
Fri, 16 Aug 2019 08:23:48 -0700 (PDT)
MIME-Version: 1.0
From: John Newbery <john@johnnewbery.com>
Date: Fri, 16 Aug 2019 11:23:37 -0400
X-Gmail-Original-Message-ID: <CAFmfg2tv4AP6GYSeHkgOYBKiWa3ia_KxWWBBjqY5u4-GkW6oLw@mail.gmail.com>
Message-ID: <CAFmfg2tv4AP6GYSeHkgOYBKiWa3ia_KxWWBBjqY5u4-GkW6oLw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a6f50905903d9310"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 16 Aug 2019 15:25:34 +0000
Subject: [bitcoin-dev] Burying CSV and segwit soft fork activations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 16 Aug 2019 15:23:52 -0000
--000000000000a6f50905903d9310
Content-Type: text/plain; charset="UTF-8"
Once a consensus change has been activated and buried by sufficient work,
we consider the height of that change to be historic fact. The exact
activation method is no longer of practical interest. In some cases the
cause of activation is not even decidable. For example, we know that segwit
activated at height 481,824 but it's debatable whether that was due to BIP
9 version bits signaling, BIP 148 UASF, or a combination of the two.
In such cases, we can significantly simplify the implementation by
hard-coding the activation height. This was done for the 3 ISM soft forks
(BIPs 34, 66 and 65) in BIP 90 [1] [2]. P2SH and segwit script enforcement
were backdated to the genesis block (with the exception of for one block)
for similar code simplification reasons [3] [4].
'Burying' deployments in this way provides a number of benefits:
1. consensus code is simplified and implementers can avoid writing and
testing code paths that are no longer relevant.
2. a hard-coded activation height is far easier to review and re-implement
than complex deployment activation logic.
3. using a non-contextual check (in this case a hard-coded constant) can
provide performance and code structure benefits (eg reducing lock
contention on blockchain data).
Bitcoin Core PR 16060 [5] was recently merged, which buries the CSV and
segwit activation heights to 419328 and 481824 respectively.
It is technically possible for this to be a non-backwards compatible
change. In the event of a re-org below the BIP9 segwit LOCKED_IN height,
this change _could_ cause a chainsplit between pre-0.19 nodes and 0.19
nodes. Such a re-org would require re-doing over 93% of the total work ever
committed to Bitcoin mining (chainwork is 0x7eb6a652531c5ad6a4b8e9 at
height 481824 compared to 0x07d75b9d25fb6602be2b51c6 at height 590393). To
quote from BIP90:
> The occurrence of such a reorg that would cause the activating block to
be disconnected would raise fundamental concerns about the security
assumptions of Bitcoin, a far bigger issue than any non-backwards
compatible change.
> So while this proposal could theoretically result in a consensus split,
it is extremely unlikely, and in particular any such circumstances would be
sufficiently damaging to the Bitcoin network to dwarf any concerns about
the effects of this proposed change.
(See the 'Considerations' section of BIP 90 for more details).
Cheers,
John
[1] https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki
[2] https://github.com/bitcoin/bitcoin/pull/8391
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015588.html
[4] https://github.com/bitcoin/bitcoin/pull/11739
[5] https://github.com/bitcoin/bitcoin/pull/16060
--000000000000a6f50905903d9310
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Once a consensus change has been activated and buried by s=
ufficient work, we consider the height of that change to be historic fact. =
The exact activation method is no longer of practical interest. In some cas=
es the cause of activation is not even decidable. For example, we know that=
segwit activated at height 481,824 but it's debatable whether that was=
due to BIP 9 version bits signaling, BIP 148 UASF, or a combination of the=
two.<br><br>In such cases, we can significantly simplify the implementatio=
n by hard-coding the activation height. This was done for the 3 ISM soft fo=
rks (BIPs 34, 66 and 65) in BIP 90 [1] [2]. P2SH and segwit script enforcem=
ent were backdated to the genesis block (with the exception of for one bloc=
k) for similar code simplification reasons [3] [4].<br><br>'Burying'=
; deployments in this way provides a number of benefits:<br><br>1. consensu=
s code is simplified and implementers can avoid writing and testing code pa=
ths that are no longer relevant.<br>2. a hard-coded activation height is fa=
r easier to review and re-implement than complex deployment activation logi=
c.<br>3. using a non-contextual check (in this case a hard-coded constant) =
can provide performance and code structure benefits (eg reducing lock conte=
ntion on blockchain data).<br><br>Bitcoin Core PR 16060 [5] was recently me=
rged, which buries the CSV and segwit activation heights to 419328 and 4818=
24 respectively.<br><br>It is technically possible for this to be a non-bac=
kwards compatible change. In the event of a re-org below the BIP9 segwit LO=
CKED_IN height, this change _could_ cause a chainsplit between pre-0.19 nod=
es and 0.19 nodes. Such a re-org would require re-doing over 93% of the tot=
al work ever committed to Bitcoin mining (chainwork is 0x7eb6a652531c5ad6a4=
b8e9 at height 481824 compared to 0x07d75b9d25fb6602be2b51c6 at height 5903=
93). To quote from BIP90:<br><br>> The occurrence of such a reorg that w=
ould cause the activating block to be disconnected would raise fundamental =
concerns about the security assumptions of Bitcoin, a far bigger issue than=
any non-backwards compatible change.<br><br>> So while this proposal co=
uld theoretically result in a consensus split, it is extremely unlikely, an=
d in particular any such circumstances would be sufficiently damaging to th=
e Bitcoin network to dwarf any concerns about the effects of this proposed =
change.<br><br>(See the 'Considerations' section of BIP 90 for more=
details).<div><br></div><div>Cheers,</div><div>John<br><br>[1] <a href=3D"=
https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki" target=3D"_=
blank">https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki</a><b=
r>[2] <a href=3D"https://github.com/bitcoin/bitcoin/pull/8391" target=3D"_b=
lank">https://github.com/bitcoin/bitcoin/pull/8391</a><br>[3] <a href=3D"ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015588.h=
tml" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-=
dev/2018-January/015588.html</a><br>[4] <a href=3D"https://github.com/bitco=
in/bitcoin/pull/11739" target=3D"_blank">https://github.com/bitcoin/bitcoin=
/pull/11739</a><br>[5] <a href=3D"https://github.com/bitcoin/bitcoin/pull/1=
6060" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/16060</a><b=
r></div></div>
--000000000000a6f50905903d9310--
|
