* Re: [bitcoin-dev] A summary of block size hardfork proposals (and a softforking one)
2015-07-30 18:14 [bitcoin-dev] A summary of block size hardfork proposals jl2012
@ 2015-07-30 20:32 ` odinn
2015-07-31 3:10 ` [bitcoin-dev] CORRECTIONS: A summary of block size hardfork proposals jl2012
1 sibling, 0 replies; 3+ messages in thread
From: odinn @ 2015-07-30 20:32 UTC (permalink / raw)
To: jl2012, bitcoin-dev
-----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-----
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] CORRECTIONS: A summary of block size hardfork proposals
2015-07-30 18:14 [bitcoin-dev] A summary of block size hardfork proposals jl2012
2015-07-30 20:32 ` [bitcoin-dev] A summary of block size hardfork proposals (and a softforking one) odinn
@ 2015-07-31 3:10 ` jl2012
1 sibling, 0 replies; 3+ messages in thread
From: jl2012 @ 2015-07-31 3:10 UTC (permalink / raw)
To: bitcoin-dev
I am making some corrections to my previous summary
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 miner voting mechanism to initiate the hardfork?
BIP100: Yes, support with 10800 out of last 12000 blocks (90%)
BIP101: Yes, support with 750 out of last 1000 blocks (75%)
BIP102: No
BIP103: No
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
# The network does not actually fork until having 90% miner support
What should be the block size at initiation?
BIP100: 1MB
BIP101: 8MB*
BIP102: 2MB
BIP103: 1MB
* It depends on the exact time of initiation, e.g. 8MB if initiated on
2016-01-11, 16MB if initiated on 2018-01-10.
Should we allow further increase / decrease?
BIP100: By miner voting, 0.5x - 2x every 12000 blocks (~3 months)
BIP101: Double every 2 years, with linear 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^
BIP101: 2016-01-11
BIP102: 2015-11-11
BIP103: 2020-12-27
^ Assuming 10 minutes blocks and votes cast before 2016-01-11 are not counted
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: 2036-01-06
BIP102: 2015-11-11
BIP103: 2063-07-09
^ permalink raw reply [flat|nested] 3+ messages in thread