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
|
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 860FCDE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Aug 2015 20:29:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com
[209.85.212.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B663B1B8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Aug 2015 20:29:11 +0000 (UTC)
Received: by wiyy7 with SMTP id y7so9761745wiy.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Aug 2015 13:29:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=2eQ/Yhg5TW4zp3B+8CF8s2kIT9BbEWYohOxntvDD+1A=;
b=I9AhhfTFJHw9eq3H7k+IfVXOfx5ma9sqwUAzbWRKXj2o2JOWp4qyHRQ7ePtEiZNLbI
BQDkKlaJpUDsk5zloodOsSOePP982tLSWCTI/ZLYIYVoLGtS7AzLoLxR0dSvtP+E8L6F
TqjZrJSTAW8PPnSfc5j2tFhaR1vUYlxEUIxiZTJLntgydzs32Y9Huv/m5IjhRyAv5/zb
qbY75LS/pQC5mKmA62GQaxan1JaXA5eDWz5bH4nAG8bI8pJRpmzrWJGQFyhRy/7jJlbS
Gf734349ZiR7yqlt2yJhFOdOf6LHAeEV+cX/TDYL3KSv5HGZhLBhe1qX+u0Lff3WmHT1
gURQ==
X-Received: by 10.194.121.163 with SMTP id ll3mr13769247wjb.142.1440793750365;
Fri, 28 Aug 2015 13:29:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.211.16 with HTTP; Fri, 28 Aug 2015 13:28:50 -0700 (PDT)
In-Reply-To: <CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Fri, 28 Aug 2015 21:28:50 +0100
Message-ID: <CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
To: Ahmed Zsales <ahmedzsales18@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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, 28 Aug 2015 20:29:12 -0000
I have received a lot of feedback on the original gist[1], reddit[2],
ML and IRC and have reworked the text somewhat.
I also request the BIP maintainer for a BIP number assignment
[1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
[2] https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/
Pull request: https://github.com/bitcoin/bips/pull/187
<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>
==Abstract==
A method of altering the maximum allowed block size of the Bitcoin protocol
using a consensus based approach.
==Motivation==
There is a belief 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.
Free voting as suggested by BIP100 allows miners to sell their votes out of band
at no risk, and enable the sponsor the ability to manipulate the blocksize.
It also provides a cost free method or the larger pools to vote in ways to
manipulate the blocksize such to disadvantage or attack smaller pools.
==Rationale==
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. Larger 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.
Using difficulty as a penalty is better than a fixed cost in bitcoins because it
is less predictable.
==Specification==
The initial block size limit shall be 1MB.
Each time a miner creates a block, they may vote to increase or decrease the
blocksize by a maximum of 10% of the current block size limit. These votes will
be used to recalculate the new block size limit every 2016 blocks.
Votes are cast using the block's coinbase field.
The first 4 bytes of the coinbase field shall be repurposed for voting as an
unsigned long integer which will be the block size in bytes.
If a miner votes for an increase, the block hash must meet a difficulty target
which is proportionally larger than the standard difficulty target based on the
percentage increase they voted for.
Votes proposing decreasing the block size limit do not need to meet a higher
difficulty target.
Miners can vote for no change by voting for the current block size.
For blocks to be valid the blockhash must meet the required difficulty target
for the vote otherwise the block is invalid and will be rejected.
Every 2016 blocks, the block size limit will be recalculated by the median of
all votes in the last 2016 blocks. This will redefine the block size limit for
the next 2016 blocks.
Blocks that are larger than the calculated base block size limit are invalid and
will be rejected.
The base block size limit may not reduce below 1MB.
==Acknowledgements==
This proposal is based on ideas and concepts derived from the writings of
Meni Rosenfeld and Gregory Maxwell.
==Copyright==
This work is placed in the public domain.
|
