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: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C2FB26C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Jan 2017 18:04:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f176.google.com (mail-ua0-f176.google.com
[209.85.217.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 612DAFD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Jan 2017 18:04:39 +0000 (UTC)
Received: by mail-ua0-f176.google.com with SMTP id v2so130764106uac.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 02 Jan 2017 10:04:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=oQtjuGwMxs4oSjTnjA+LVfy21vQVs1IEoAQfDpNPx0M=;
b=MvmFmRw0VRJi3AGqG6TJSNGp1kjzlMPvqfC12Avyj/98uMu8sBJs1UQP6Tw4b+dafa
cy4QAOYzIm+yDcBFah9PB+18obZ/xX0JaNTv2TP7pruP+Hb7Ewf5i4tSA2iOs/Xh5ScN
qswkfjLLqKA446XyCRtk5yzE9hCsOcVP2+0tRd1McvsmhQsHoPgll8Xg+Y658LxJzy99
G0HB4mufPBqQrZRj0kS53SC2EYGj0LxNC668MRYANQxSCVSGlbp+Z2ETdxT7Fv9PR5+I
gMUCerkEiHTkMDS468TkhsAmMa9pcsXNMMz9x8t2K258JRVU8rHgEYusCHG1P/HDaW4S
o5oA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=oQtjuGwMxs4oSjTnjA+LVfy21vQVs1IEoAQfDpNPx0M=;
b=R051ydwAF7tM++9Xu1ZQzUpND/bwD6DHQ62YEQ/aW9RuBMElvS9IE3UQ829kj5Hjph
3/cbZSP55j95karpPsJc0jze8ilP3xT2nLpJmToEsxy8h6hxcnnobfUwnuRhKPj25wA2
3mcslHdyUO0fYEHj2HAhZMH8gegGejwRZ4N1jGlGN0g0uO4nT/DTBR3IPNakhXwWUyK2
c2z+ynlOwHcqBtcywPAid6ZPhxOVZf5fR7xDtGwJDdqJQRwrsEPfypLzxFxePT59aK3H
Q5Ltbn14rzPO56Z/QT5zYGy7yBnBpXQ1mVzs9/cWAbqBVAx78hYNaBPWNfYcwJehfmJe
9lTA==
X-Gm-Message-State: AIkVDXJcAVTLXYvR87G/h+2y3wpbtsxsikdc8/guss3KJ3Bf8YnDso2eV1aafZfHN4ByO3tu4TE2Ipqoqws8tQ==
X-Received: by 10.159.48.203 with SMTP id k11mr41915644uab.42.1483380278310;
Mon, 02 Jan 2017 10:04:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Mon, 2 Jan 2017 10:04:37 -0800 (PST)
From: "t. khan" <teekhan42@gmail.com>
Date: Mon, 2 Jan 2017 13:04:37 -0500
Message-ID: <CAGCNRJoN7u3yvzitH2KSmVty-p0tX9jxWLHPb8uO5CPZmxmoRg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f403045e34f48e3bb0054520627f
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] BIP - 'Block75' - New algorithm
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Mon, 02 Jan 2017 18:04:39 -0000
--f403045e34f48e3bb0054520627f
Content-Type: text/plain; charset=UTF-8
Based on feedback from this list and further simulations, here is a new
algorithm for Block75:
new max blocksize = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY)
TARGET_CAPACITY = 0.75
AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a
decimal
x = current max block size
Please note that this algorithm actually tries to keep blocks 75% full,
unlike the old one that unnecessarily capped growth at 250KB. While this
would theoretically allow a maximum increase of 25% over the previous max
block size, in practice it's not possible to get that high.
This would be calculated every 2016 blocks along with difficulty.
Block75 should maintain transaction fees at about the level they were in
May/June 2016 when blocks started hitting 75% full somewhat consistently.
Thoughts? For any predictions as to how this would behave, please provide
the numbers used to arrive at any conclusions.
Other questions:
1. How do we make Block75 play nice with SegWit?
2. Is there any need for a minimum max blocksize? Block75 allows for
decreasing the size as well as increasing it.
Activation:
To help negate some of the risk associated with a hard fork and to prevent
a single relatively small mining pool from blocking Block75's adoption,
activation would occur once 900 of the last 1,000 blocks mined signaled
support, with a grace period of 4,032 blocks.
Thank you again to all those who commented on the previous Block75 thread.
Together, we can make 2017 the year the block size debate ends (hopefully
forever).
Happy New Year!
- t.k.
--f403045e34f48e3bb0054520627f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Based on feedback from this list and further simulati=
ons, here is a new algorithm for Block75:</div><div><br></div>new max block=
size =3D x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY)<div><br></div><div><=
div>TARGET_CAPACITY =3D 0.75</div><div>AVERAGE_CAPACITY =3D average percent=
age full of the last 2016 blocks, as a decimal</div><div>x =3D current max =
block size</div><div><br></div><div>Please note that this algorithm actuall=
y tries to keep blocks 75% full, unlike the old one that unnecessarily capp=
ed growth at 250KB. While this would theoretically allow a maximum increase=
of 25% over the previous max block size, in practice it's not possible=
to get that high.</div><div><br></div><div>This would be calculated every =
2016 blocks along with difficulty.</div><div><br></div><div>Block75 should =
maintain transaction fees at about the level they were in May/June 2016 whe=
n blocks started hitting 75% full somewhat consistently.</div><div><br></di=
v><div>Thoughts? For any predictions as to how this would behave, please pr=
ovide the numbers used to arrive at any conclusions.</div><div><br></div><d=
iv>Other questions:</div><div>1. How do we make Block75 play nice with SegW=
it?<br></div><div>2. Is there any need for a minimum max blocksize? Block75=
allows for decreasing the size as well as increasing it.</div></div><div><=
br></div><div>Activation:</div><div>To help negate some of the risk associa=
ted with a hard fork and to prevent a single relatively small mining pool f=
rom blocking Block75's adoption, activation would occur once 900 of the=
last 1,000 blocks mined signaled support, with a grace period of 4,032 blo=
cks.</div><div><br></div><div>Thank you again to all those who commented on=
the previous Block75 thread. Together, we can make 2017 the year the block=
size debate ends (hopefully forever).</div><div><br></div><div>Happy New Y=
ear!</div><div><br></div><div>- t.k.</div></div>
--f403045e34f48e3bb0054520627f--
|
