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
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 91FBE8F4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 22:23:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com
[209.85.160.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1ECC0115
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 22:23:12 +0000 (UTC)
Received: by ykbi184 with SMTP id i184so84685865ykb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 15:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type
:content-transfer-encoding;
bh=Rl+/GiROgdmwdKZ4HcMMCkfSOnnSXqY1mLKwhWuZ1hE=;
b=LY8SQEqMVkEqfVKp7Hfq0fi5z9q/2WXZriIx4zJ50E2g2K/GJp6ecmnJnHuUCfTC02
M8c/QDIVIzZ8CFX5JQ57mFsbN3XiKWT6tI8/9O5khl0MyuJZgd6BUeu2moRCsBIp2UKQ
/FGGU2G/398e7lEfn1tKzB//K7TltcNSBS5KrIXgzH+dbBUSECOtzeMCDnqnO35D2187
Q/fP4zi8gqiZK6Zn9IB9o43IFiLFh0zNqtkDZAdo3wJl48WBFfMflmFqiAWdBLdWoadt
2HdPszAYttZnkblKBToxjCWUZ6N5+/kkKwD3YANYHNY9pDrKH4n+LVhVy+auns0CmuEP
FO7A==
X-Received: by 10.13.247.3 with SMTP id h3mr15604840ywf.142.1440195791289;
Fri, 21 Aug 2015 15:23:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.94.132 with HTTP; Fri, 21 Aug 2015 15:22:51 -0700 (PDT)
From: Btc Drak <btcdrak@gmail.com>
Date: Fri, 21 Aug 2015 23:22:51 +0100
Message-ID: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_40,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
HK_RANDOM_FROM, 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: [bitcoin-dev] Consensus based block size retargeting algorithm
(draft)
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, 21 Aug 2015 22:23:12 -0000
I wanted to offer a potential way to adjust the block size limit in a
democratic way without making it easy to game. This is meant only as a
starting point for a general idea. Thresholds and exact figures and
the details of the algorithm are up for debate, and possibly some
formula based determination.
The living document is currently a gist available at
https://gist.github.com/btcdrak/1c3a323100a912b605b5
<pre>
BIP: XX
Title: Consensus based block size retargeting algorithm
Author: BtcDrak <btcdrak@gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-08-21
</pre>
=3D=3DAbstract=3D=3D
A method of altering the maximum allowed block size of the Bitcoin
protocol using a consensus based approach.
=3D=3DMotivation=3D=3D
There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase due to a
mass adoption curve, because co-ordinating a hard fork takes
considerable time, and being unable to respond in a timely manner
would irreparably harm the credibility of bitcoin.
Additionally, predetermined block size increases are problematic
because they attempt to predict the future, and if too large could
have unintended consequences like damaging the possibility for a fee
market to develop as block subsidy decreases substantially over the
next 9 years; introducing or exacerbating mining attack vectors; or
somehow affect the network in unknown or unpredicted ways. Since fixed
changes are hard to deploy, the damage could be extensive.
Dynamic block size adjustments also suffer from the potential to be
gamed by the larger hash power.
=3D=3DRationale=3D=3D
By introducing a cost to increase the block size ensures the mining
community will collude to increase it only when there is a clear
necessity, and reduce it when it is unnecessary. Rogue miners cannot
force their wishes so easily because not only will they have to pay
extra a difficulty target, then can be downvoted at no cost by the
objecting hash power.
=3D=3DSpecification=3D=3D
The initial "base block size limit" shall be 1MB.
Miners can vote for a block size increase by signalling the proposed
percentage increase of the "base block size limit" in the coinbase
field. For the vote to be considered valid the block they mine must
meets a difficulty target which is proportionally larger than the
standard difficulty target based on the percentage increase they voted
for. If a miner does not vote, or the vote is invalid, it shall be
counted as a vote for no change.
Miners may vote the size down by signalling in the coinbase field
without paying a difficulty penalty.
Every 2016 blocks, the maximum allowed block size will be recalculated
by the average of all votes in the last 2016 blocks, i.e. sum each
vote from each block and divide by 2016 then multiply by the base
block size limit. This will redefine the base block size limit for the
next 2016 blocks.
Blocks that are larger than the calculated base block size limit are
invalid and MUST be rejected.
The maximum change up or down each retargeting period shall be limited
to 10% of the base block size limit.
The maximum block size may not increase above 8MB.
Votes shall be cast by adding the following human readable multiplier
to the coinbase string =E2=80=9C/BXn.nnn/=E2=80=9D where valid votes would =
exist
between the ranges =E2=80=9C/BX0.900/=E2=80=9D (10% decrease) and =E2=80=9C=
/BX1.100/=E2=80=9D (10%
increase). =E2=80=9C/BX1.000/=E2=80=9D would be a vote for no change. Inval=
id votes
will be counted as a vote for no change: =E2=80=9C/BX1.000/=E2=80=9D.
=3D=3DAcknowledgements=3D=3D
This proposal is based on ideas and concepts derived from the writings
of Meni Rosenfeld and Gregory Maxwell.
=3D=3DCopyright=3D=3D
This work is placed in the public domain.
|
