odinn [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-30 📝 Original message:-----BEGIN PGP SIGNED ...
📅 Original date posted:2015-07-30
📝 Original message:-----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 at 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-----
📝 Original message:-----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 at 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-----