Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F0AE7F38
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 22:27:41 +0000 (UTC)
Received: by mail-ig0-f177.google.com with SMTP id m11so4641586igk.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
	<9a02d94fbc78afaa3e9668e0294eef64@xbt.hk>
Date: Wed, 16 Dec 2015 17:27:40 -0500
Message-ID: <CADm_Wca9zTdTc2gvTxrWkFjfA49KhbU_=uNXh_mZ+QYXGZ6wWg@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: jl2012 <jl2012@xbt.hk>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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.

--047d7bd6bca8093b7305270b6a96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Dec 16, 2015 at 1:36 PM, jl2012 <span dir=3D"ltr">=
&lt;<a href=3D"mailto:jl2012@xbt.hk" target=3D"_blank">jl2012@xbt.hk</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">4. In the miners round table on the second day=
, one of the devs mentioned that he didn&#39;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.<br></blockquote><div=
><br></div><div>This was a very interesting dynamic, and seems fair (menu).=
</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">6. I b=
elieve we should avoid a radical &quot;Economic Change Event&quot; 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&#39;s better than nothing for BIP101 proponents. By &quo=
t;early&quot; I mean to be effective by May, at least 2 months before the h=
alving.<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br=
></div><div><br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<br>(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<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div></div></div=
></div>

--047d7bd6bca8093b7305270b6a96--