Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B77F6E8D for ; Thu, 17 Dec 2015 06:12:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 944A8187 for ; Thu, 17 Dec 2015 06:12:42 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id no2so49883237obc.3 for ; Wed, 16 Dec 2015 22:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yyl/4NTguv6f2WGtS1tCSmt6pKQElBW9ybBLcmK6rqE=; b=zDBsCQ4TWtMzc3ozraacULpIKIRb8b8tjmr/mtfIMQAlwAiW88uXRAZgzRJxe5yjYh ElyTAQL90ezoaMLuna69ncqsQbsDxs9S6BcUqNO3XEEfpHTc+W17hAytQ3yiNP6vDOsU BDGSH6ilvR3okyxy8NvaUKVJJUnbTzmTZdGSOSbmCkU73nCQQo0I105WFwUdsCzNjWv+ sx+bTOvn23YhgKd+ybByl9tJdG5BkSshsgEBZPmOm0uRiz0bAMd3VYWnSXlFVl7eZQfi EEwJRIPHX4XmhSosqR4u9nT90ePWEz6XObpLtm6pn0Canlmznljv9Tuxlq6h7ItXyelG QGwg== MIME-Version: 1.0 X-Received: by 10.60.43.170 with SMTP id x10mr39470730oel.68.1450332761840; Wed, 16 Dec 2015 22:12:41 -0800 (PST) Sender: dscotese@gmail.com Received: by 10.60.135.101 with HTTP; Wed, 16 Dec 2015 22:12:41 -0800 (PST) In-Reply-To: References: <9a02d94fbc78afaa3e9668e0294eef64@xbt.hk> Date: Wed, 16 Dec 2015 22:12:41 -0800 X-Google-Sender-Auth: Tv9FyjoMK9vYjJAfLZuJ8PmNP3g Message-ID: From: Dave Scotese To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a11330c941371e6052711e968 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 06:12:43 -0000 --001a11330c941371e6052711e968 Content-Type: text/plain; charset=UTF-8 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 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 and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --001a11330c941371e6052711e968 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wui= lle via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:
> I indeed think we can communicate much b= etter 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.=C2=A0 No one has that power, actually, at least not legitimately.=C2= =A0 All we can do is build it and hope enough people find it acceptable to = adopt.=C2=A0 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.=C2=A0 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 t= he 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, D= ec 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 decisio= n 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.
<= br>
This was a very interesting dynamic, and seems fair (m= enu).

=C2=A0
6. I believe we should avoid a radical "Economic Chang= e Event" at least in the next halving cycle, as Bitcoin was designed t= o bootstrap the adoption by high mining reward in the beginning. For this r= eason, 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 BIP1= 01 proponents. By "early" I mean to be effective by May, at least= 2 months before the halving.

Th= at was precisely my logic for picking May 5 as the hard fork date.=C2=A0 So= me buffer before halving, enough for caution and iteration in the meantime.=



=C2=A0

(c) My most optimistic guess is SW will be ready in 6 months, which wil= l 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: =C2=A0update dev lib (bitcoin-core.js/bitcoinj) + release cycle, updat= e app + release cycle, for most actors in the ecosystem, on top of the Bitc= oin Core roll out.



=

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev




--
I like to provide some work at no charge to pr= ove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm th= e webmaster for T= he Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante= .
"He ought to find it more profitable to play by the rules" -= Satoshi Nakamoto
--001a11330c941371e6052711e968--