summaryrefslogtreecommitdiff
path: root/6a/22359d5cb1909728cf496a1e95d970892bbe07
blob: c4945c6db289c48863b018894d6cf62b3fac9d5c (plain)
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
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
Return-Path: <marcel@jamin.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DFF0DF6A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 30 Dec 2015 13:57:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com
	[209.85.160.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D087F89
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 30 Dec 2015 13:57:08 +0000 (UTC)
Received: by mail-yk0-f173.google.com with SMTP id x67so154199403ykd.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 30 Dec 2015 05:57:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=jamin-net.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=JdA9ap4fYGz5KLurcith+0fQAqWp1b8uxkOWqu1kCc0=;
	b=eU6gC9zO4vomuzqyj61z/UC1is+PrLDLcMy/uAZ1NcLNAgr+4kGNtLrJRFxGPn5D1K
	z/pzla5jDSDTdnVeVbCl0UkOZ11wVZljasVNnSgHfzbNLnVDjwPVWRAgB8pO95Phd3JQ
	75Pf+XBK5rz41vo1FMMc9s1ZIgY9y+y56BsbsGX+RcTNnvct4wbdBLYldUdP6tfOoRdJ
	9DDhTkTRPLvmjNvvMf6SnlsB9nvMHKLJKJUVBhxhM0+ED91wWEwd1X1w3AusTskE6eop
	wyOTaRC9m9E8L4/QGv7zTT/BBxkZnKOwuS69l2Wt+n1R9kWYbUE1KfCeDZgvtgNIPSwR
	QIGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=JdA9ap4fYGz5KLurcith+0fQAqWp1b8uxkOWqu1kCc0=;
	b=KsxawMeV8R/c1X1AROoAudF0VGZ4a2A8cSck248xEBjwh2sXr/KRDUwoTcG+jv7kuR
	GnIEdgF/WxMgjcXJ8dqZNEADfabgVYwIrHkQLDs/UZo+eMA8U8K4BQndv/8Z5PFO75oX
	he1g3HcgVBQM1lJn/FekBMMU7jC4ZmTIdQDG0TL8JDoIXtf+szWVrUCWR2+pUIqvHGv1
	q9HlQ939jfyJWAV8bx6DW6uzsSjqMi7KZZFus9LRrfR1M99I9wkBd3lp3+g6Zc0GBSWm
	ny2q3ip6BM1IfrxOO3IGmXCMVRV7k0N9rRmOmlqtjG7gRl2FJi7ZewY9+iMI2EBjCxsc
	mUbw==
X-Gm-Message-State: ALoCoQlaPH5cWH1YY1VVgkIh3reDN+axVPMtadRBa8mtYUeuDxiPUsFieeK9aw9PNRkYtb0s5uKPLfCsMNrUdnPuC9wRhSOlIw==
MIME-Version: 1.0
X-Received: by 10.129.138.195 with SMTP id a186mr47155201ywg.325.1451483828080;
	Wed, 30 Dec 2015 05:57:08 -0800 (PST)
Received: by 10.13.248.6 with HTTP; Wed, 30 Dec 2015 05:57:08 -0800 (PST)
In-Reply-To: <8E12B367-1A55-435F-9244-101C09094BDA@toom.im>
References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org>
	<8E12B367-1A55-435F-9244-101C09094BDA@toom.im>
Date: Wed, 30 Dec 2015 14:57:08 +0100
Message-ID: <CAAUq484dsvTSKTazj=J0zaqJxNQkSVyBS9H8pGZzDNyKhw_eVQ@mail.gmail.com>
From: Marcel Jamin <marcel@jamin.net>
To: Jonathan Toomim <j@toom.im>
Content-Type: multipart/alternative; boundary=94eb2c080440f8863405281de919
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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
X-Mailman-Approved-At: Wed, 30 Dec 2015 16:48:24 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
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: Wed, 30 Dec 2015 13:57:10 -0000

--94eb2c080440f8863405281de919
Content-Type: text/plain; charset=UTF-8

I guess the same could be said about the softfork flavoured SW
implementation. In any case, the strategy pattern helps with code structure
in situations like this.

2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> As a first impression, I think this proposal is intellectually
> interesting, but crufty and hackish and should never actually be deployed.
> Writing code for Bitcoin in a future in which we have deployed a few
> generalized softforks this way sounds terrifying.
>
> Instead of this:
>
>     CTransaction GetTransaction(CBlock block, unsigned int index) {
>         return block->vtx[index];
>     }
>
> We might have this:
>
>     CTransaction GetTransaction(CBlock block, unsigned int index) {
>         if (!IsBIP102sBlock(block)) {
>             return block->vtx[index];
>         } else {
>             if (!IsOtherGeneralizedSoftforkBlock(block)) {
>                 // hooray! only one generalized softfork level to deal
> with!
>                 return
> LookupBlock(GetGSHashFromCoinbase(block->vtx[0].vin[0].scriptSig))->vtx[index];
>            } else {
>                throw NotImplementedError; // I'm too lazy to write
> pseudocode this complicated just to argue a point
>         }
>     }
>
> It might be possible to make that a bit simpler with recursion, or by
> doing subsequent generalized softforks in a way that doesn't have
> multi-levels-deep block-within-a-block-within-a-block stuff. Still: ugh.
>
>
>
>
> On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Below is a proof-of-concept implementation of BIP102 as a softfork:
> >
> > https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
> >
> https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize
> >
> > BIP102 is normally a hardfork.  The softfork version (unofficial
> > codename BIP102s) uses the idea described here:
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
> >
> > The basic idea is that post-fork blocks are constructed in such a way
> > they can be mapped to valid blocks under the pre-fork rules.  BIP102s
> > is a softfork in the sense that post-fork miners are still creating a
> > valid chain under the old rules, albeit indirectly.
> >
> > From the POV of non-upgraded clients, BIP102s circumvents the
> > block-size limit by moving transaction validation data "outside" of
> > the block.  This is a similar trick used by Segregated Witness and
> > Extension Blocks (both softfork proposals).
> >
> > From the POV of upgraded clients, the block layout is unchanged,
> > except:
> > - A larger 2MB block-size limit (=BIP102);
> > - The header Merkle root has a new (backwards compatible)
> >  interpretation;
> > - The coinbase encodes the Merkle root of the remaining txs.
> > Aside from this, blocks maintain their original format, i.e. a block
> > header followed by a vector of transactions.  This keeps the
> > implementation simple, and is distinct from SW and EB.
> >
> > Since BIP102s is a softfork it means that:
> > - A miner majority (e.g. 75%, 95%) force miner consensus (100%).  This
> >  is not true for a hardfork.
> > - Fraud risk is significantly reduced (6-conf unlikely depending on
> >  activation threshold).
> > This should address some of the concerns with deploying a block-size
> > increase using a hardfork.
> >
> > Notes:
> >
> > - The same basic idea could be adapted to any of the other proposals
> >  (BIP101, 2-4-8, BIP202, etc.).
> > - I used Jeff Garzik's BIP102 implementation which is incomplete (?).
> >  The activation logic is left unchanged.
> > - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my
> >  code :-(
> >
> > --joe
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c080440f8863405281de919
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I guess the same could be said about the softfork flavoure=
d SW implementation. In any case, the strategy pattern helps with code stru=
cture in situations like this.</div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-d=
ev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</spa=
n>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">As a first impression, I think this p=
roposal is intellectually interesting, but crufty and hackish and should ne=
ver actually be deployed. Writing code for Bitcoin in a future in which we =
have deployed a few generalized softforks this way sounds terrifying.<br>
<br>
Instead of this:<br>
<br>
=C2=A0 =C2=A0 CTransaction GetTransaction(CBlock block, unsigned int index)=
 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return block-&gt;vtx[index];<br>
=C2=A0 =C2=A0 }<br>
<br>
We might have this:<br>
<br>
=C2=A0 =C2=A0 CTransaction GetTransaction(CBlock block, unsigned int index)=
 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!IsBIP102sBlock(block)) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return block-&gt;vtx[index];<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!IsOtherGeneralizedSoftforkBl=
ock(block)) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // hooray! only one=
 generalized softfork level to deal with!<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return LookupBlock(=
GetGSHashFromCoinbase(block-&gt;vtx[0].vin[0].scriptSig))-&gt;vtx[index];<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throw NotImplemented=
Error; // I&#39;m too lazy to write pseudocode this complicated just to arg=
ue a point<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 }<br>
<br>
It might be possible to make that a bit simpler with recursion, or by doing=
 subsequent generalized softforks in a way that doesn&#39;t have multi-leve=
ls-deep block-within-a-block-within-a-block stuff. Still: ugh.<br>
<br>
<br>
<br>
<br>
On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br>
<br>
&gt; Below is a proof-of-concept implementation of BIP102 as a softfork:<br=
>
&gt;<br>
&gt; <a href=3D"https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize" r=
el=3D"noreferrer" target=3D"_blank">https://github.com/ZoomT/bitcoin/tree/2=
015_2mb_blocksize</a><br>
&gt; <a href=3D"https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksi=
ze...ZoomT:2015_2mb_blocksize?diff=3Dsplit&amp;name=3D2015_2mb_blocksize" r=
el=3D"noreferrer" target=3D"_blank">https://github.com/jgarzik/bitcoin/comp=
are/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=3Dsplit&amp;name=3D2=
015_2mb_blocksize</a><br>
&gt;<br>
&gt; BIP102 is normally a hardfork.=C2=A0 The softfork version (unofficial<=
br>
&gt; codename BIP102s) uses the idea described here:<br>
&gt; <a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015=
-December/012073.html" rel=3D"noreferrer" target=3D"_blank">http://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html</a><br>
&gt;<br>
&gt; The basic idea is that post-fork blocks are constructed in such a way<=
br>
&gt; they can be mapped to valid blocks under the pre-fork rules.=C2=A0 BIP=
102s<br>
&gt; is a softfork in the sense that post-fork miners are still creating a<=
br>
&gt; valid chain under the old rules, albeit indirectly.<br>
&gt;<br>
&gt; From the POV of non-upgraded clients, BIP102s circumvents the<br>
&gt; block-size limit by moving transaction validation data &quot;outside&q=
uot; of<br>
&gt; the block.=C2=A0 This is a similar trick used by Segregated Witness an=
d<br>
&gt; Extension Blocks (both softfork proposals).<br>
&gt;<br>
&gt; From the POV of upgraded clients, the block layout is unchanged,<br>
&gt; except:<br>
&gt; - A larger 2MB block-size limit (=3DBIP102);<br>
&gt; - The header Merkle root has a new (backwards compatible)<br>
&gt;=C2=A0 interpretation;<br>
&gt; - The coinbase encodes the Merkle root of the remaining txs.<br>
&gt; Aside from this, blocks maintain their original format, i.e. a block<b=
r>
&gt; header followed by a vector of transactions.=C2=A0 This keeps the<br>
&gt; implementation simple, and is distinct from SW and EB.<br>
&gt;<br>
&gt; Since BIP102s is a softfork it means that:<br>
&gt; - A miner majority (e.g. 75%, 95%) force miner consensus (100%).=C2=A0=
 This<br>
&gt;=C2=A0 is not true for a hardfork.<br>
&gt; - Fraud risk is significantly reduced (6-conf unlikely depending on<br=
>
&gt;=C2=A0 activation threshold).<br>
&gt; This should address some of the concerns with deploying a block-size<b=
r>
&gt; increase using a hardfork.<br>
&gt;<br>
&gt; Notes:<br>
&gt;<br>
&gt; - The same basic idea could be adapted to any of the other proposals<b=
r>
&gt;=C2=A0 (BIP101, 2-4-8, BIP202, etc.).<br>
&gt; - I used Jeff Garzik&#39;s BIP102 implementation which is incomplete (=
?).<br>
&gt;=C2=A0 The activation logic is left unchanged.<br>
&gt; - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my<b=
r>
&gt;=C2=A0 code :-(<br>
&gt;<br>
&gt; --joe<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--94eb2c080440f8863405281de919--