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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bip@mattwhitlock.name>) id 1YqcZv-000371-Ol
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 07:20:11 +0000
X-ACL-Warn:
Received: from resqmta-ch2-01v.sys.comcast.net ([69.252.207.33])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1YqcZu-0000yy-13
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 07:20:11 +0000
Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116])
by resqmta-ch2-01v.sys.comcast.net with comcast
id RKL41q0042XD5SV01KL4Qj; Fri, 08 May 2015 07:20:04 +0000
Received: from crushinator.localnet
([IPv6:2601:6:4800:47f:1e4e:1f4d:332c:3bf6])
by resomta-ch2-20v.sys.comcast.net with comcast
id RKL31q0012JF60R01KL4jb; Fri, 08 May 2015 07:20:04 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: bitcoin-development@lists.sourceforge.net
Date: Fri, 08 May 2015 03:20:02 -0400
Message-ID: <16096345.A1MpJQQkRW@crushinator>
User-Agent: KMail/4.14.7 (Linux/3.18.11-gentoo; KDE/4.14.7; x86_64; ; )
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [69.252.207.33 listed in list.dnswl.org]
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 T_FROM_12LTRDOM From a 12-letter domain
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YqcZu-0000yy-13
Subject: [Bitcoin-development] Proposed alternatives to the 20MB step
function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 07:20:11 -0000
Between all the flames on this list, several ideas were raised that did not get much attention. I hereby resubmit these ideas for consideration and discussion.
- Perhaps the hard block size limit should be a function of the actual block sizes over some trailing sampling period. For example, take the median block size among the most recent 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically, rather than having human beings guessing at what is an appropriate limit.
- Perhaps the hard block size limit should be determined by a vote of the miners. Each miner could embed a desired block size limit in the coinbase transactions of the blocks it publishes. The effective hard block size limit would be that size having the greatest number of votes within a sliding window of most recent blocks.
- Perhaps the hard block size limit should be a function of block-chain length, so that it can scale up smoothly rather than jumping immediately to 20 MB. This function could be linear (anticipating a breakdown of Moore's Law) or quadratic.
I would be in support of any of the above, but I do not support Mike Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the road without actually solving the problem, and it does so in a controversial (step function) way.
|
