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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 62F85CF8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 09:39:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2BCA41AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 09:39:38 +0000 (UTC)
Received: from localhost ([::1]:48702 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZVcac-0029P7-HF; Sat, 29 Aug 2015 05:38:22 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 29 Aug 2015 05:38:17 -0400
From: jl2012@xbt.hk
To: Btc Drak <btcdrak@gmail.com>
In-Reply-To: <CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
<CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
Message-ID: <a04470a99e83f521a6a778e0921855ee@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Sat, 29 Aug 2015 09:39:47 -0000
We need some game theory experts to analyse this but I see there are 3
major problems:
1. Tragedy of the commons: Some miners have to scarify their income to
increase the block size, and all miners will share the beneficial
outcome of the increase. All miners would like to be free riders.
2. Promote the formation of mining cartel: miners have to make sure that
their vote for increase is supported by at least 50% of miners, or they
will lose income for nothing. A miner also needs to make sure that he is
not voting "excessively" (in terms of size and vote count), as the
excessive part will never be counted due to the use of median. So
basically you will either have exactly 1009 miners voting for the same
size increase in a cycle, or have no vote for increase at all. That will
require a lot of offline negotiations. Such cartel may work ONLY if
mining is highly centralized, and miners trust each other. Also, there
is no mechanism to punish those who betray the cartel.
3. Imbalance of power: it is costly to increase the size, while totally
free to decrease the size
Btc Drak via bitcoin-dev 於 2015-08-28 16:28 寫到:
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
