1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
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">=
<<a href=3D"mailto:jl2012@xbt.hk" target=3D"_blank">jl2012@xbt.hk</a>>=
;</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'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 "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.<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--
|
