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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
Return-Path: <will.madden@novauri.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C5AA1ACB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 15:13:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com
[209.85.220.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2D56219B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 15:13:42 +0000 (UTC)
Received: by qkei195 with SMTP id i195so18215224qke.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 08:13:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:content-type:mime-version:subject:from
:in-reply-to:date:cc:content-transfer-encoding:message-id:references
:to; bh=SlDr08Jnutk3ViquNH4jS3wbktdAQxOz7Uuj43K/qno=;
b=Vd2KO0Rz3+pfrf8V9NbD/lyjyR+pjvDVjgLdzn2ovufh8DcGnuD5QRjP5HrAgCfF4N
HIq6DFzeltg0IDJwcbes6QGc+X7B4amOAu/14WRCRS6GFoiXiPiwwI1q5ydGAOvdmioG
3gsCckDe66q38+pj0tfEzqmQFp0s4OR8j84bLVoTt9yT9bO05INJeWllayv8mgGMMhhh
6za82xn6uXXb5n3DdB2A7mVPMosffJC36g4G3qJ8npdoKQIXmVI+dZrYgXXK31yP9Id4
36mAGlPIuxivsiCkAwrUT98BXgE1wcvU0PETV8J+ux5PV9GqxysLtARX/1FtxC1st0/e
ws4g==
X-Gm-Message-State: ALoCoQlDPjK4jOFH2jYfS7msvFC6q8gp4rfI1amKSt/DTTwsODbgWgmDrbv6MXUNhtzkNR9FbyK+
X-Received: by 10.55.24.166 with SMTP id 38mr4891446qky.70.1435331621248;
Fri, 26 Jun 2015 08:13:41 -0700 (PDT)
Received: from [10.149.72.46] (mobile-107-107-56-238.mycingular.net.
[107.107.56.238])
by mx.google.com with ESMTPSA id l33sm6968549qkh.12.2015.06.26.08.13.39
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 26 Jun 2015 08:13:40 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83
Mime-Version: 1.0 (1.0)
From: Will <will.madden@novauri.com>
X-Mailer: iPhone Mail (12F70)
In-Reply-To: <CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
Date: Fri, 26 Jun 2015 11:13:38 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <19956282-19CC-4150-8865-F211774AF70E@novauri.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com>
<CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com>
<0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com>
<CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.com>
<CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE,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-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
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: Fri, 26 Jun 2015 15:13:42 -0000
--Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Make the default soft vote =3D to previous max block size * 1.09 every 12k (=
or whatever mirrors the hard cap growth rate) and don't allow voting to lowe=
r the soft limit and I think you have something.
You need a default that grows because most miners are lazy and will do squir=
relly things like hard code 8000000 as their vote permanently. =20
Make the lazy miners' default choice grow at the hard cap growth rate and yo=
u should be ok if you want voting.
> On Jun 26, 2015, at 9:47 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
>=20
>> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org> wrote:
>> The hard-cap serves the purpose of a safety limit in case our
>> understanding about the economics, incentives or game-theory is wrong
>> worst case.
>=20
> True.
>=20
> BIP 100 and 101 could be combined. Would that increase consensus?
>=20
> - Miner vote threshold reached
> - Wait notice period or until earliest start time
> - Block size default target set to 1 MB
> - Soft limit set to 1MB
> - Hard limit set to 8MB + double every 2 years
> - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB=
minimum)
>=20
> Block size updates could be aligned with the difficulty setting and based o=
n the last 2016 blocks.
>=20
> Miners could leave the 1MB limit in place initially. The vote is to get t=
he option to increase the block size.
>=20
> Legacy clients would remain in the network until >80% of miners vote to ra=
ise the limit and a miner produces a >1MB block.
>=20
> If the growth rate over-estimates hardware improvements, the devs could ad=
d a limit into the core client. If they give notice and enough users update=
, then miners would have to accept it.
>=20
> The block size becomes min(miner's vote, core devs). Even if 4 years noti=
ce is given, blocks would only be 4X optimal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Make the default soft vote =3D to prev=
ious max block size * 1.09 every 12k (or whatever mirrors the hard cap growt=
h rate) and don't allow voting to lower the soft limit and I think you have s=
omething.</div><div><br></div><div>You need a default that grows because mos=
t miners are lazy and will do squirrelly things like hard code 8000000 as th=
eir vote permanently. </div><div><br></div><div>Make the lazy miners' d=
efault choice grow at the hard cap growth rate and you should be ok if you w=
ant voting.<br></div><div><br>On Jun 26, 2015, at 9:47 AM, Tier Nolan <<a=
href=3D"mailto:tier.nolan@gmail.com">tier.nolan@gmail.com</a>> wrote:<br=
><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">On Thu, Jun 25, 2=
015 at 3:07 PM, Adam Back <span dir=3D"ltr"><<a href=3D"mailto:adam@cyphe=
rspace.org" target=3D"_blank">adam@cypherspace.org</a>></span> wrote:<br>=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">
The hard-cap serves the purpose of a safety limit in case our<br>
understanding about the economics, incentives or game-theory is wrong<br>
worst case.<br></blockquote><div><br></div><div>True.<br><br>BIP 100 and 101=
could be combined. Would that increase consensus?<br><br></div><div>-=
Miner vote threshold reached<br></div><div>- Wait notice period or until ea=
rliest start time<br></div><div>- Block size default target set to 1 MB<br><=
/div><div>- Soft limit set to 1MB<br></div><div>- Hard limit set to 8MB + do=
uble every 2 years<br></div><div>- Miner vote to decide soft limit (lowest s=
ize ignoring bottom 20% but 1MB minimum)<br><br></div><div>Block size update=
s could be aligned with the difficulty setting and based on the last 2016 bl=
ocks.<br></div><br>Miners could leave the 1MB limit in place initially. =
; The vote is to get the option to increase the block size.<br></div><div cl=
ass=3D"gmail_quote"><div><br>Legacy clients would remain in the network unti=
l >80% of miners vote to raise the limit and a miner produces a >1MB b=
lock.<br><br></div><div>If the growth rate over-estimates hardware improveme=
nts, the devs could add a limit into the core client. If they give not=
ice and enough users update, then miners would have to accept it.<br><br></d=
iv><div>The block size becomes min(miner's vote, core devs). Even if 4=
years notice is given, blocks would only be 4X optimal.<br></div></div></di=
v></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=
--Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83--
|
