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
|
Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 51EC312A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 13:28:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B81CC10F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 13:28:07 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
(may be forged)) (authenticated bits=0)
by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tBUDS3WJ030430
(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Wed, 30 Dec 2015 05:28:05 -0800
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_E8EC9A5F-95A4-4FFC-8068-E514E8CA7DC7";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Jonathan Toomim <j@toom.im>
In-Reply-To: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org>
Date: Wed, 30 Dec 2015 05:29:05 -0800
Message-Id: <8E12B367-1A55-435F-9244-101C09094BDA@toom.im>
References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org>
To: joe2015@openmailbox.org
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVavtly3mPwDMDizXaXjRYhsZWpkuaUJqla11ZE0AFxobfdXsBCKHyUZgGngCU4H4OL5vUAwbmeFrBByvtcOR7ot
X-Sonic-ID: C;ouKgJ/mu5RGKicgxU3XIUw== M;xlFEKPmu5RGKicgxU3XIUw==
X-Sonic-Spam-Details: 3.8/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Cc: 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:28:08 -0000
--Apple-Mail=_E8EC9A5F-95A4-4FFC-8068-E514E8CA7DC7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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[in=
dex];
} 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:
>=20
> https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
> =
https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015=
_2mb_blocksize?diff=3Dsplit&name=3D2015_2mb_blocksize
>=20
> 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/01207=
3.html
>=20
> 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.
>=20
> =46rom 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).
>=20
> =46rom the POV of upgraded clients, the block layout is unchanged,
> except:
> - A larger 2MB block-size limit (=3DBIP102);
> - 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.
>=20
> 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.
>=20
> Notes:
>=20
> - 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 :-(
>=20
> --joe
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_E8EC9A5F-95A4-4FFC-8068-E514E8CA7DC7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWg9whAAoJEIEuMk4MG0P1iW8H/ie47pnBcQXkB36LKP9UEceh
fTGBsrImiNnDEUt07vu+7qHe8ia3s4+sX/6j6x+baJ0TRUU+elG4j5dsU+SwScBr
oaWsYFIS/kNS9NeoQ+l/vXz5VUHPCbajCbNVR/nubrgHujx1tf1I1pNoIRd5e824
IlPw++MQkka5c6k1ufYarynuvdrft2izTqe2oOGlrHQ12P63mu1XwsWXcdIkFa7O
cuuCo2X05VMk6PADJ1+KqG4iKImOKtukaB/aGoHoFrkf5k1o8ajjMqBSptrmaf3T
LflnMjcAqGKiNPp1kB63+Bl4JgTGvhMqIsdO/EQwzfqS8KxXwm0qwVql52oJmyk=
=pEPv
-----END PGP SIGNATURE-----
--Apple-Mail=_E8EC9A5F-95A4-4FFC-8068-E514E8CA7DC7--
|
