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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
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 96A9E19EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 07:40:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com
[209.85.220.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16E6B138
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 07:40:04 +0000 (UTC)
Received: by pablk4 with SMTP id lk4so79392369pab.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 09 Oct 2015 00:40:03 -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=MV09GQDSjOOKAhVlgtx1q/ZUY1hKYKciY827e1Ugm3Q=;
b=HB0tcQfLYX5TtVpnnnvkJ6ewrFe3Es9Y55Q+PpXWMYm2hrtSc7OGZR/0zDPL4DCdW7
bKhEMswFgfzB0uMmLo+klNv4JL4+T4K9Ka2PbUIbiW8oBXVLCNuL79bVGlc9g8inFt81
4PCl44rxxydo40prk/mMu5TMYVrYEfjr9BVAtV+ZsQiKvr001XiPe7EJ26bDwDV4UPrB
1day9KNyMHZ73CuPM+Y2hMtzAePvOrWXVjBwp8G3A7j6lehzMUDxdwjg0bm+1DLqcg/t
NNLiAqTnX+Uz3kmV0JXJEBy7Jy+pl0iYvtga8LQcKLV+aUqOIXnQ2ysmp4GAJ09gzTFZ
Zegw==
X-Received: by 10.68.241.234 with SMTP id wl10mr13610114pbc.27.1444376403737;
Fri, 09 Oct 2015 00:40:03 -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 ol3sm530838pbb.49.2015.10.09.00.40.02
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Fri, 09 Oct 2015 00:40:03 -0700 (PDT)
From: "Eric Lombrozo" <elombrozo@gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Fri, 09 Oct 2015 07:39:59 +0000
Message-Id: <em78f4e69c-a3ca-4fdd-9f5f-23aeb7e25358@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="------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68"
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] Fw: 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 07:40:04 -0000
--------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
I wanted to clarify that this goal is for AFTER the next release in case=
=20
that didn't come across. The point is just to ascertain interest and=20
start thinking ahead. VersionBits can be fully ready to go well before=20
then and is well underway.
------ Forwarded Message ------
From: "Eric Lombrozo" <elombrozo@gmail.com>
To: "bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
Sent: 10/8/2015 8:58:12 PM
Subject: Making soft forks pluggable
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
--------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68
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>
<STYLE>#xeae4b2a51df74b2094b4c61376a0809b BLOCKQUOTE.cite
{PADDING-LEFT: 10px; MARGIN-LEFT: 5px; BORDER-LEFT: #cccccc 1px solid; PADD=
ING-RIGHT: 0px; MARGIN-RIGHT: 0px}
#xeae4b2a51df74b2094b4c61376a0809b BLOCKQUOTE.cite2
{PADDING-TOP: 0px; PADDING-LEFT: 10px; MARGIN-LEFT: 5px; BORDER-LEFT: #cccc=
cc 1px solid; MARGIN-TOP: 3px; PADDING-RIGHT: 0px; MARGIN-RIGHT: 0px}
#xeae4b2a51df74b2094b4c61376a0809b .plain PRE, #xeae4b2a51df74b2094b4c61376=
a0809b .plain TT
{FONT-SIZE: 100%; FONT-FAMILY: monospace; WHITE-SPACE: pre-wrap; FONT-WEIGH=
T: normal; FONT-STYLE: normal}
#xeae4b2a51df74b2094b4c61376a0809b A IMG
{BORDER-TOP: 0px; BORDER-RIGHT: 0px; BORDER-BOTTOM: 0px; BORDER-LEFT: 0px}
#xeae4b2a51df74b2094b4c61376a0809b .plain PRE, #xeae4b2a51df74b2094b4c61376=
a0809b .plain TT, #xeae4b2a51df74b2094b4c61376a0809b
{FONT-SIZE: 12pt; FONT-FAMILY: Tahoma}
</STYLE>
</HEAD>
<BODY scroll=3Dauto class>
<DIV>I wanted to clarify that this goal is for AFTER the next release in=
case that didn't come across. The point is just to ascertain interest and=
start thinking ahead. VersionBits can be fully ready to go well before =
then and is well underway.</DIV>
<DIV> </DIV>
<DIV>------ Forwarded Message ------</DIV>
<DIV>From: "Eric Lombrozo" <<A href=3D"mailto:elombrozo@gmail.com">elomb=
rozo@gmail.com</A>></DIV>
<DIV>To: "bitcoin-dev" <<A href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</A>></DIV>
<DIV>Sent: 10/8/2015 8:58:12 PM</DIV>
<DIV>Subject: Making soft forks pluggable</DIV>
<DIV> </DIV>
<DIV id=3Dxeae4b2a51df74b2094b4c61376a0809b>
<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></DIV></BODY></HTML>
--------=_MB32BE87DE-80D1-4524-AEBE-8F2FA5BA5B68--
|
