[bitcoin-dev] Block size: It's economics & user preparation & moral hazard

Jeff Garzik jgarzik at gmail.com
Wed Dec 16 22:27:40 UTC 2015

On Wed, Dec 16, 2015 at 1:36 PM, jl2012 <jl2012 at xbt.hk> wrote:

> 4. In the miners round table on the second day, one of the devs mentioned
> that he didn't want to be seen as the decision maker of Bitcoin. On the
> other hand, Chinese miners repeatedly mentioned that they want several
> concrete proposals from devs which they could choose. I see no
> contradiction between these 2 viewpoints.

This was a very interesting dynamic, and seems fair (menu).

> 6. I believe we should avoid a radical "Economic Change Event" at least in
> the next halving cycle, as Bitcoin was designed to bootstrap the adoption
> by high mining reward in the beginning. For this reason, I support an early
> and conservative increase, such as BIP102 or 2-4-8. 2MB is accepted by most
> people and it's better than nothing for BIP101 proponents. By "early" I
> mean to be effective by May, at least 2 months before the halving.

That was precisely my logic for picking May 5 as the hard fork date.  Some
buffer before halving, enough for caution and iteration in the meantime.

> (c) My most optimistic guess is SW will be ready in 6 months, which will
> be very close to halving and potential tx volume burst. And it may not be
> done in 2016, as it does not only involve consensus code, but also change
> in the p2p protocol and wallet design

Not just wallet design -- you have to game through the standard steps of:
 update dev lib (bitcoin-core.js/bitcoinj) + release cycle, update app +
release cycle, for most actors in the ecosystem, on top of the Bitcoin Core
roll out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/9123a94f/attachment.html>

More information about the bitcoin-dev mailing list