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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 25879323
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 13:47:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com
[209.85.220.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 78AEFF2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 13:47:25 +0000 (UTC)
Received: by qkhu186 with SMTP id u186so55249740qkh.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 06:47:24 -0700 (PDT)
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:cc
:content-type; bh=8sjR4DbgUpGuAweoKLS32llK/4ovDkBZ6K8fnhLv6TY=;
b=iYwDjubYQbZAw9DfeFv7vYKySrVjROqa+iwG+Xi2SsjXNfFtI4aJcp8uvsNrqhCrAY
fEKT3QAKAZniFSZW3tSEjLaoCnZz6ZXuapWmq0WEjhMtTq9qgr/U7e93bIXJsfCYJhWl
vI23d8yppm/B68WDq+4xGTyEEAaVvq6qMJ2Bs+XJo6tksD4UWPn/MtVWuLRYVyYrclid
sqtAIrWzKgauP9Q5VaRBI4rlZPS90mmzyQW/N2u0pI92oJhHZos8RsDLuT+0l2kpzcN1
9wUrft5basn1byKBqsFcuksBgUgSqkdMrcvQ4gYxsB/NIRaWQQ+RPKVRpMvyjTea4o/0
8smw==
MIME-Version: 1.0
X-Received: by 10.140.237.147 with SMTP id i141mr2399647qhc.25.1435326444653;
Fri, 26 Jun 2015 06:47:24 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Fri, 26 Jun 2015 06:47:24 -0700 (PDT)
In-Reply-To: <CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.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>
Date: Fri, 26 Jun 2015 14:47:24 +0100
Message-ID: <CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135ad28ded44d05196bfa25
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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 13:47:26 -0000
--001a1135ad28ded44d05196bfa25
Content-Type: text/plain; charset=UTF-8
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.
>
True.
BIP 100 and 101 could be combined. Would that increase consensus?
- 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)
Block size updates could be aligned with the difficulty setting and based
on the last 2016 blocks.
Miners could leave the 1MB limit in place initially. The vote is to get
the option to increase the block size.
Legacy clients would remain in the network until >80% of miners vote to
raise the limit and a miner produces a >1MB block.
If the growth rate over-estimates hardware improvements, the devs could add
a limit into the core client. If they give notice and enough users update,
then miners would have to accept it.
The block size becomes min(miner's vote, core devs). Even if 4 years
notice is given, blocks would only be 4X optimal.
--001a1135ad28ded44d05196bfa25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <span dir=3D"lt=
r"><<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cyphe=
rspace.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_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 10=
1 could be combined.=C2=A0 Would that increase consensus?<br><br></div><div=
>- Miner vote threshold reached<br></div><div>- Wait notice period or until=
earliest 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=
+ double every 2 years<br></div><div>- Miner vote to decide soft limit (lo=
west size ignoring bottom 20% but 1MB minimum)<br><br></div><div>Block size=
updates could be aligned with the difficulty setting and based on the last=
2016 blocks.<br></div><br>Miners could leave the 1MB limit in place initia=
lly.=C2=A0 The vote is to get the option to increase the block size.<br></d=
iv><div class=3D"gmail_quote"><div><br>Legacy clients would remain in the n=
etwork until >80% of miners vote to raise the limit and a miner produces=
a >1MB block.<br><br></div><div>If the growth rate over-estimates hardw=
are improvements, the devs could add a limit into the core client.=C2=A0 If=
they give notice and enough users update, then miners would have to accept=
it.<br><br></div><div>The block size becomes min(miner's vote, core de=
vs).=C2=A0 Even if 4 years notice is given, blocks would only be 4X optimal=
.<br></div></div></div></div>
--001a1135ad28ded44d05196bfa25--
|
