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
|
Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 435C940D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 20:32:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E60E149
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 20:32:14 +0000 (UTC)
Received: from cotinga.riseup.net (unknown [10.0.1.161])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id 0181242180;
Thu, 30 Jul 2015 20:32:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1438288333; bh=85gbtEwr6zDfV4X3c2xu6N4Y7+jpjgAphgLrqc6Pu0I=;
h=Date:From:To:Subject:References:In-Reply-To:From;
b=cXHLHpYg+H4mdRdMk2ARkbzN4rz3leGdpC1FClKx/uxWZ6QJwLbD0/qijSh3/qT52
/8W0Xanlf/VfYXC1pf+RK6vMVGBnKAFYvSxRqlKY3lMxul+65E5/95D718+Jz3WikD
aeVWVdV4bV/1nka5liutaQojw9s944S3mD4jzRkI=
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla)
with ESMTPSA id 885331C03CE
Message-ID: <55BA89CB.5080806@riseup.net>
Date: Thu, 30 Jul 2015 13:32:11 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: jl2012@xbt.hk, "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
References: <20150730181450.Horde.mXJp1wMjXROJvXZ_Vhv2RQ2@server47.web-hosting.com>
In-Reply-To: <20150730181450.Horde.mXJp1wMjXROJvXZ_Vhv2RQ2@server47.web-hosting.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1
X-Virus-Status: Clean
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] A summary of block size hardfork proposals (and a
softforking one)
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: Thu, 30 Jul 2015 20:32:15 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Great summary, thanks. Helpful to get general grasp of the main
things out there.
On 07/30/2015 11:14 AM, jl2012 via bitcoin-dev wrote:
> Currently, there are 4 block size BIP by Bitcoin developers:
>
> BIP100 by Jeff:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
> BIP101 by Gavin:
> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
> BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
> BIP??? by Pieter (called "BIP103" below):
> https://gist.github.com/sipa/c65665fc360ca7a176a6
>
> To facilitate further discussion, I'd like to summarize these
> proposals by a series of questions. Please correct me if I'm wrong.
> Something like sigop limit are less controversial and are not
> shown.
>
> Should we use a BIP34-like voting mechanism to initiate the
> hardfork? BIP100, 102, 103: No BIP101: Yes
>
> When should we initiate the hardfork? BIP100: 2016-01-11 BIP101: 2
> weeks after 75% miner support, but not before 2016-01-11 BIP102:
> 2015-11-11 BIP103: 2017-01-01
>
> What should be the block size at initiation? BIP100: 1MB BIP101:
> 8MB BIP102: 2MB BIP103: 1MB
>
> Should we allow further increase / decrease? BIP100: By miner
> voting, 0.5x - 2x every 12000 blocks (~3 months) BIP101: Double
> every 2 years, with interpolations in between (41.4% p.a.) BIP102:
> No BIP103: +4.4% every 97 days (double every 4.3 years, or 17.7%
> p.a.)
>
> The earliest date for a >=2MB block? BIP100: 2016-04-03 (assuming
> 10 minutes block) BIP101: 2016-01-11 BIP102: 2015-11-11 BIP103:
> 2020-12-27
>
> What should be the final block size? BIP100: 32MB is the max, but
> it is possible to reduce by miner voting BIP101: 8192MB BIP102:
> 2MB BIP103: 2048MB
>
> When should we have the final block size? BIP100: Decided by
> miners BIP101: 30 years after initiation BIP102: 2015-11-11 BIP103:
> 2063-07-09
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
I'd like to add to this some remarks that are from an earlier discussion
Cameron Garnham added into a thread, at
http://bitcoin-development.narkive.com/iHmMh6bZ/bitcoin-development-prop
osed-alternatives-to-the-20mb-step-function#post65
"First off, I am glad that the idea of dynamic block size adjustment is
gaining some attention, in particular the model that I proposed.
I wanted to take some time and explain some of the philosophy of how,
and why, I proposed this this particular model.
When Bitcoin was first made, there was a 32MB block size limit; this
was quickly found to be open to spam (and potentially DOS, as the code
was not-at-all optimized to support large blocks), and was reduced to
1MB, this was a quick fix that was never intended to last; at some
point the network should come to an understanding, a consensus if you
will, of what (and how much) belongs in a block.
The core point of this is that miners have always, and will always;
hold the power, to decide what goes into blocks; this implicitly,
obviously, includes how large blocks are. Miners are able to come any
sort of agreement they wish, providing the bitcoin clients accept
their blocks as valid."
(...)
"the proposal introducing a consensus protocol for block sizes;
instead of just having a hard limit (enforced by everyone), instead,
we have a constant factor above the average block size over a fixed
intervals that is soft-forked by only the miners. (The next simplest
mathematical construct).
This proposal is entirely a soft-fork and may be implemented without
changing any client code what so ever. In-fact, it could be
implemented by only a simple 51% majority of miners, with-or-without
gaining the wider community consensus."
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuonLAAoJEGxwq/inSG8CensH/29IwToehXVgEA44RZmUsIdn
5d2OCGZHOsinJKS9Uqtd5SfIDycXVVTV832KrxIUH1oC685iwVzBuA4hJQc2Z49A
hNKs97N97iS2s3W6X/llbYz/3i3H6TQaCJGfK+XurFi6pxdC+4LgoUovtGaIsc8x
z7iTD5F7FEhPmKU6uxw9GRRvKHJwyy0xWWNgBAJjdS7F5y7DR1VC9RhPehpU75Wt
MGHrrogM41r+cNVDpNpnT42q0rAKC0IXjvY43ZoA/EFUoWkpaXI6jwKXtjqDjCP7
P8StjQ7eoeIkZWu1PwbfKStbF4Ob3Q7Xi+hQxCwciKdtfsLRFkdamzvpl/qh9wg=
=Itr1
-----END PGP SIGNATURE-----
|
