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

From: Dave Scotese <dscotese@litmocracy•com>
To: Jeff Garzik <jgarzik@gmail•com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Wed, 16 Dec 2015 22:12:41 -0800	[thread overview]
Message-ID: <CAGLBAhfWS4089mcN8FmFcu19r9EwyBMS=TO_2ak3g28UHNXnvg@mail.gmail.com> (raw)
In-Reply-To: <CADm_Wca9zTdTc2gvTxrWkFjfA49KhbU_=uNXh_mZ+QYXGZ6wWg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3383 bytes --]

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.

I'm not a core dev, so maybe I have the power to change the consensus
rules.  No one has that power, actually, at least not legitimately.  All we
can do is build it and hope enough people find it acceptable to adopt.  Who
doesn't want to hard fork to 2MB blocks on May 5th and why not?

I have a bitcoin to be split up among all those who suffer from a May 5,
2016 hardfork to 2MB blocks if they can prove it to me, or prove it to
enough engineers that I succumb to peer pressure.  I would have to respect
the engineers though.

There!

Now that we've agreed to have a hard fork on May 5th, 2016, we might decide
to implement some other methods of avoiding the FFM, like braiding the
blockchain or flexcap, or just let anyone mining on top of a block make one
that is a five or ten Kb larger.

notplato

On Wed, Dec 16, 2015 at 2:27 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Wed, Dec 16, 2015 at 1:36 PM, jl2012 <jl2012@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.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 5087 bytes --]