From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F0AE7F38 for ; Wed, 16 Dec 2015 22:27:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 270F8CB for ; Wed, 16 Dec 2015 22:27:41 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id m11so4641586igk.1 for ; Wed, 16 Dec 2015 14:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pj9aYBaX3HHCxBXweek5XYMHAbWyIKkSL61Y/KVp4sI=; b=tDTxprRApkVbi3t7PwrgByLdhT1q4jJsKLN+dHfSuOj56Y9qixhDl/2MC1lBx5dWeC DcDEnEpGTClHU8aTeKMmB/nx3+ITTJqjBkIk+PNHwRpd8JZ61Iu4AhDatl1+aiSNbIXN tVQ1wYKhMNs1oHeq9fdEUhdy3jkAoF1hXXO38ScQHzRTNBFAAsakGpRf/U2+4C2XUb1v OYXrBaXk1+/SFFVGOSAcxbFcaCHd77/YywQ3OmJpz/qNde2B8LA7Ey5KW5eFxS5aa2JP 5JanNZcWs7fM9xdImL5PE9boQjTD63TRPL3ltB2Ng8yeBL8dscalfZkiy5SsqMr7jgmP vvHQ== MIME-Version: 1.0 X-Received: by 10.50.29.110 with SMTP id j14mr186271igh.87.1450304860660; Wed, 16 Dec 2015 14:27:40 -0800 (PST) Received: by 10.79.8.198 with HTTP; Wed, 16 Dec 2015 14:27:40 -0800 (PST) In-Reply-To: <9a02d94fbc78afaa3e9668e0294eef64@xbt.hk> References: <9a02d94fbc78afaa3e9668e0294eef64@xbt.hk> Date: Wed, 16 Dec 2015 17:27:40 -0500 Message-ID: From: Jeff Garzik To: jl2012 Content-Type: multipart/alternative; boundary=047d7bd6bca8093b7305270b6a96 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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: Wed, 16 Dec 2015 22:27:42 -0000 --047d7bd6bca8093b7305270b6a96 Content-Type: text/plain; charset=UTF-8 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. --047d7bd6bca8093b7305270b6a96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 decis= ion maker of Bitcoin. On the other hand, Chinese miners repeatedly mentione= d that they want several concrete proposals from devs which they could choo= se. I see no contradiction between these 2 viewpoints.

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

=C2=A0
6. I b= elieve we should avoid a radical "Economic Change Event" at least= in the next halving cycle, as Bitcoin was designed to bootstrap the adopti= on by high mining reward in the beginning. For this reason, I support an ea= rly 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 &quo= t;early" I mean to be effective by May, at least 2 months before the h= alving.

That was precisely my logic for= picking May 5 as the hard fork date.=C2=A0 Some buffer before halving, eno= ugh 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

N= ot just wallet design -- you have to game through the standard steps of: = =C2=A0update dev lib (bitcoin-core.js/bitcoinj) + release cycle, update app= + release cycle, for most actors in the ecosystem, on top of the Bitcoin C= ore roll out.



--047d7bd6bca8093b7305270b6a96--