summaryrefslogtreecommitdiff
path: root/43/b0eebb9114ebb0d4750ccab187945172e309f7
blob: 65fdb46c29dc15a742f698d53ed62da8ae6e3b6e (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
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1015DA06
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 13 Nov 2015 19:37:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 85A3018C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 13 Nov 2015 19:37:16 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 4E7F238A6F46;
	Fri, 13 Nov 2015 19:37:04 +0000 (UTC)
X-Hashcash: 1:25:151113:bitcoin-dev@lists.linuxfoundation.org::37zZa87cUO7IHA2Z:astnl
X-Hashcash: 1:25:151113:erik.fors@startmail.com::1OmVu1d9GJb+wfmv:qDId
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Erik <erik.fors@startmail.com>
Date: Fri, 13 Nov 2015 19:37:02 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; )
References: <5645E095.4050704@startmail.com>
In-Reply-To: <5645E095.4050704@startmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201511131937.03430.luke@dashjr.org>
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP proposal - Max block size
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, 13 Nov 2015 19:37:17 -0000

On Friday, November 13, 2015 1:07:33 PM Erik via bitcoin-dev wrote:
> Hi devs. I was discussing the BIP proposals concerning max block size
> yesterday in the #bitcoin channel. I believe that BIP101 fully utilized
> will outperform consumer hardware soon or later and thereby centralize
> Bitcoin. I would therefore like to do a different proposal:

It doesn't look like you've considered BIP103 or newer BIPs? Especially, I'd 
suggest you look at and work with John Sacco who just the other day posted a 
BIP draft very similar-looking to yours. My overall impression of your summary 
is that it is unnecessarily over-complicated and underspecified. How does the 
2^(1/2) block size limit actually work? This is not a very precise number, so 
it seems liable to produce rounding errors in different implementations. 
Additionally, the miner voting thing seems pointless since miners can already 
softfork lower limits. It would be beneficial to express the current 
possibility so full nodes can enforce it, but this would be expressed as an 
unlimited simple-majority vote to reduce the limit. Probably it would be ideal 
to separate this off from the hardfork BIP, since it's fairly tangent to it.

Luke