summaryrefslogtreecommitdiff
path: root/28/6ee4b1a3ea16f57ac3e90918f9002b6e243247
blob: 33fc51017b2d3f865abef06f6a8e5ba761a0036a (plain)
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
Return-Path: <1240902@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 85A2CB01
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 25 Aug 2015 09:19:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com
	[209.85.223.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AEDF1129
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 25 Aug 2015 09:19:28 +0000 (UTC)
Received: by iods203 with SMTP id s203so179292433iod.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 25 Aug 2015 02:19:28 -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:to
	:cc:content-type;
	bh=viruWsbQ/2X9LtfujVp0uu2HC/p5U7TsN+bRwiutBAI=;
	b=kqgoJN7VRnobwjdLRUnlMctTsiYKHezqxHwlX47xNwzKX5PISCa/r/zhhjLlyuA7h5
	k01HlhKJe4BB+HHcrsJJsj5rURHb4aQr5urDJQO4QnwNJlvRGyOVFZbYnB5zmVIGWM17
	Q3ZxoCkKZlKFK1+rAEJGBW0xSwiu8xcMBjqnOfv/+BSNo08BrjnVZizMYECMMbbENaQl
	DYKqL6yEwxtNkCXAUTYXo9zd+BIqB+S8XdUvOD7zdMYCKg9FnvOrYKYp9iQ4yOLc/sWm
	S48jKBTCfHb5NxVwX8LIYdlg3U1Y/H1dHErWZzyiOOYtlWoQ+dECq6LBCvFAWcHglpMo
	X+NA==
MIME-Version: 1.0
X-Received: by 10.107.19.81 with SMTP id b78mr25356522ioj.36.1440494368174;
	Tue, 25 Aug 2015 02:19:28 -0700 (PDT)
Received: by 10.107.10.159 with HTTP; Tue, 25 Aug 2015 02:19:28 -0700 (PDT)
In-Reply-To: <CAED3CWipF8u5g3LUrqfyHxvEk4Lu+d12ZOJZnoBUw6iZZOg-ZQ@mail.gmail.com>
References: <CAED3CWipF8u5g3LUrqfyHxvEk4Lu+d12ZOJZnoBUw6iZZOg-ZQ@mail.gmail.com>
Date: Tue, 25 Aug 2015 17:19:28 +0800
Message-ID: <CAFzgq-x9GBbqARyhMgfSPc=wYeBgzXy4VUQ0D76GC+TCAxWDuA@mail.gmail.com>
From: Chun Wang <1240902@gmail.com>
To: Upal Chakraborty <bitcoin@upalc.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	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@lists.linuxfoundation.org, greg@xiph.org
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
 [BIP 1xx - 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: Tue, 25 Aug 2015 09:19:29 -0000

Proposal 1 looks good, but tx fee collected can be manipulated by
miners. I like the idea next block collect the tx fee from previous
block.

On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Github:
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
>
> <pre>
>   BIP: 1xx
>   Title: Dynamically Controlled Bitcoin Block Size Max Cap
>   Author: Upal Chakraborty <bitcoin@upalc.com>
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-08-24
> </pre>
>
> ==Abstract==
>
> This BIP proposes replacing the fixed one megabyte maximum block size with a
> dynamically controlled maximum block size that may increase or decrease with
> difficulty change depending on various network factors. I have two proposals
> regarding this...
>
> i. Depending only on previous block size calculation.
>
> ii. Depending on previous block size calculation and previous Tx fee
> collected by miners.
>
> ==Motivation==
>
> With increased adoption, transaction volume on bitcoin network is bound to
> grow. If the one megabyte max cap is not changed to a flexible one which
> changes itself with changing network demand, then adoption will hamper and
> bitcoin's growth may choke up. Following graph shows the change in average
> block size since inception...
>
> https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
>
> ==Specification==
>
> ===Proposal 1 : Depending only on previous block size calculation===
>
>   If more than 50% of block's size, found in the first 2000 of the last
> difficulty period, is more than 90% MaxBlockSize
>       Double MaxBlockSize
>   Else if more than 90% of block's size, found in the first 2000 of the last
> difficulty period, is less than 50% MaxBlockSize
>       Half MaxBlockSize
>   Else
>       Keep the same MaxBlockSize
>
> ===Proposal 2 : Depending on previous block size calculation and previous Tx
> fee collected by miners===
>
>   TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008
> blocks in last 2 difficulty period
>   TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008
> blocks in last 2 difficulty period (This actually includes 8 blocks from
> last but one difficulty)
>
>   TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks
> in last 2 difficulty period
>   TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in
> last 2 difficulty period (This actually includes 8 blocks from last but one
> difficulty)
>
>   If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 >
> 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
> TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty >
> TotalBlockSizeInLastButOneDifficulty) )
>       MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
> TotalBlockSizeInLastButOneDifficulty
>   Else If ( ( (Sum of first 4016 block size in last 2 difficulty
> period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty <
> TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty <
> TotalBlockSizeInLastButOneDifficulty) )
>       MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
> TotalBlockSizeInLastButOneDifficulty
>   Else
>       Keep the same MaxBlockSize
>
> ==Rationale==
>
> These two proposals have been derived after discussion on
> [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and
> [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
> bitcoin-dev mailing list]. The original idea and its evolution in the light
> of various arguements can be found [http://upalc.com/maxblocksize.php here].
>
> ===Proposal 1 : Depending only on previous block size calculation===
>
> This solution is derived directly from the indication of the problem. If
> transaction volume increases, then we will naturally see bigger blocks. On
> the contrary, if there are not enough transaction volume, but maximum block
> size is high, then only few blocks may sweep the mempool. Hence, if block
> size is itself taken into consideration, then maximum block size can most
> rationally be derived. Moreover, this solution not only increases, but also
> decreases the maximum block size, just like difficulty.
>
> ===Proposal 2 : Depending on previous block size calculation and previous Tx
> fee collected by miners===
>
> This solution takes care of stable mining subsidy. It will not increase
> maximum block size, if Tx fee collection is not increasing and thereby
> creating a Tx fee pressure on the market. On the other hand, though the
> block size max cap is dynamically controlled, it is very difficult to game
> by any party because the increase or decrease of block size max cap will
> take place in the same ratio of average block size increase or decrease.
>
> ==Compatibility==
>
> This is a hard-forking change to the Bitcoin protocol; anybody running code
> that fully validates blocks must upgrade before the activation time or they
> will risk rejecting a chain containing larger-than-one-megabyte blocks.
>
> ==Other solutions considered==
>
> [http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making
> Decentralized Economic Policy] - by Jeff Garzik
>
> [https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap with
> rollover penalties] - by Meni Rosenfeld
>
> [https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increase
> maximum block size] - by Gavin Andresen
>
> [https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following
> technological growth] - by Pieter Wuille
>
> [https://lightning.network/lightning-network-paper.pdf The Bitcoin Lightning
> Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus
> Dryja
>
> ==Deployment==
>
> If consensus is achieved, deployment can be made at a future block number at
> which difficulty will change.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>