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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0680D11D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 03:58:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com
[209.85.220.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8729416D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 03:58:17 +0000 (UTC)
Received: by pacex6 with SMTP id ex6so73986583pac.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 08 Oct 2015 20:58:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:to:subject:date:message-id:reply-to:user-agent:mime-version
:content-type; bh=GXTbJ1sWyOTeFKQ49ZyPixjbh6wwb+VkoMDvaeeXMMY=;
b=VzxSUXkR16ZLMour4SfSflJyDHlbBqIafAhDVs9warC3NM3gXWgA24TgWxKng7phAp
taWx2hbae2BpZtsopilaUfb/5r9iO4z1mXGEnOftFSVJY6C2suThPxAMxkEvJxfnwikt
6yYWAx685KDBTWE0haLVsIPUlGLI5QjJwbkDXqaZA1gNQ6E3vfDhIQOQcZm5XNSvLzy4
+WCrAEycqPSreRvNOEsUcHeqabuv91Vm9hvlOTRlWTOKVzsjH54mbSiAcZSg0NhUgpcb
Ad7VbNx4xAY774Yq4kzZMplbleZ2rl1bBuHVTSxnHuUVg1wA0bHgEpQLf7u82odlNpLd
Lo1g==
X-Received: by 10.66.66.166 with SMTP id g6mr7737428pat.152.1444363097281;
Thu, 08 Oct 2015 20:58:17 -0700 (PDT)
Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
ze3sm10017290pac.5.2015.10.08.20.58.16
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thu, 08 Oct 2015 20:58:16 -0700 (PDT)
From: "Eric Lombrozo" <elombrozo@gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Fri, 09 Oct 2015 03:58:12 +0000
Message-Id: <em9172c2aa-5388-48dc-9d68-b942bdd936e3@platinum>
Reply-To: "Eric Lombrozo" <elombrozo@gmail.com>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Making soft forks pluggable
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 09 Oct 2015 03:58:18 -0000
--------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Before I scare anyone away, please here me out:
It occurs to me it wouldn't be all that difficult to support the ability=
=20
to define soft forks entirely as standalone units that can be trivially=20
merged with Bitcoin Core. It would require a few changes in some places=20
in the consensus code, but at least for a very wide class of potential=20
soft forks, all cases could be covered via only a small number of hooks,=
=20
primarily in main.cpp, consensus/*, script/interpreter.cpp, and=20
primitives/*. (Other hooks could be added in non-consensus code such as=20
rpcblockchain.cpp or the wallet). It would be possible to build unit=20
tests for each soft fork independently and compare enforcement of=20
different combinations (as well as simulate these deployment=20
combinations on regtest).
Before I get too heavily invested in this idea, though, I'd like to see=20
if there are any reasonable objections to such a thing. Of course,=20
refactors are generally disruptive in the short-term...but I think what=20
I'm talking about can be done without having to move very large chunks=20
of code around, with very specifically defined hooks that can be easily=20
documented to make backports fairly simple.
My biggest concern (other than being able to convince everyone that we=20
won't break anything, which of course I'd have to do a good job of in=20
terms of rigor) is whether supporting this feature is a good idea in the=
=20
first place. There's something to be said for it not being *too* easy to=
=20
write and deploy a soft fork...however, unless we open this up a little=20
more and make such deployments more routine (and safe) it will take a=20
very long time to deploy stuff. A significant motivation behind=20
VersionBits (BIP0009) is to make such deployments faster, so if we're=20
already doing that perhaps we might as well take this initiative even=20
further.
If others think this is a good idea I'll start writing up a detailed=20
plan. (NOTE: The current versionbits deployment plan does not require=20
this. I am working on an implementation of versionbits that could=20
potentially support this plan but doesn't have to.)
If I'm very wrong, I am all ears to *sincere* objections.
- Eric
--------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px;=
padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: normal; font-style: normal; white-space: pre-wrap; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}</STYLE>
</HEAD>
<BODY>
<DIV>Before I scare anyone away, please here me out:</DIV>
<DIV> </DIV>
<DIV>It occurs to me it wouldn't be all that difficult to support the abili=
ty to define soft forks entirely as standalone units that can be trivially=
merged with Bitcoin Core. It would require a few changes in some places=
in the consensus code, but at least for a very wide class of potential =
soft forks, all cases could be covered via only a small number of hooks,=
primarily in main.cpp, consensus/*, script/interpreter.cpp, and primitives=
/*. (Other hooks could be added in non-consensus code such as rpcblockchain=
.cpp or the wallet). It would be possible to build unit tests for each soft=
fork independently and compare enforcement of different combinations (as=
well as simulate these deployment combinations on regtest).</DIV>
<DIV> </DIV>
<DIV>Before I get too heavily invested in this idea, though, I'd like to=
see if there are any reasonable objections to such a thing. Of course, =
refactors are generally disruptive in the short-term...but I think what =
I'm talking about can be done without having to move very large chunks of=
code around, with very specifically defined hooks that can be easily docum=
ented to make backports fairly simple.</DIV>
<DIV> </DIV>
<DIV>My biggest concern (other than being able to convince everyone=
that we won't break anything, which of course I'd have to do a good=
job of in terms of rigor) is whether supporting this feature is a good =
idea in the first place. There's something to be said for it not being=
*too* easy to write and deploy a soft fork...however, unless we open this=
up a little more and make such deployments more routine (and safe) it=
will take a very long time to deploy stuff. A significant motivation behin=
d VersionBits (BIP0009) is to make such deployments faster, so if we're =
already doing that perhaps we might as well take this initiative even furth=
er.</DIV>
<DIV> </DIV>
<DIV>If others think this is a good idea I'll start writing up a detailed=
plan. (NOTE: The current versionbits deployment plan does not require this=
. I am working on an implementation of versionbits that could potentially=
support this plan but doesn't have to.)</DIV>
<DIV> </DIV>
<DIV>If I'm very wrong, I am all ears to *sincere* objections.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>- Eric</DIV></BODY></HTML>
--------=_MB4BEFD619-C10B-40A4-9BFD-A2A34241EE94--
|
