summaryrefslogtreecommitdiff
path: root/de/b54c170f9dabe316a3619214926d12b719f69d
blob: 745aaf5c62a31b25e3995199041634ccf3b91ac9 (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
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 2939B12C1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 00:20:06 +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 AB65D265
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 00:20:05 +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 7550010801BA;
	Thu,  3 Sep 2015 00:17:44 +0000 (UTC)
X-Hashcash: 1:25:150903:bitcoin-dev@lists.linuxfoundation.org::gjJx0xEjHcqAcGZI:ck/GL
X-Hashcash: 1:25:150903:jgarzik@gmail.com::17pr+yc=vZvLaHgn:g3hha
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Jeff Garzik <jgarzik@gmail.com>
Date: Thu, 3 Sep 2015 00:17:42 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.1-gentoo-r1; KDE/4.14.8; x86_64; ; )
References: <CADm_WcZpOxLJdxENe=GXqrp17C-Q2karunOvzegGz-NQ2b_AEg@mail.gmail.com>
	<CADm_WcZEbAe_+VXxS1eMKQ1SM3KiJwVDS50-GtfUPw-Mdd5O2w@mail.gmail.com>
In-Reply-To: <CADm_WcZEbAe_+VXxS1eMKQ1SM3KiJwVDS50-GtfUPw-Mdd5O2w@mail.gmail.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: <201509030017.43036.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_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 100 repo
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: Thu, 03 Sep 2015 00:20:06 -0000

On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev 
wrote:
> The repo: https://github.com/jgarzik/bip100

What is the purpose of the newly added 1 MB floor? It seems clear from the 
current information available that 1 MB is presently too high for the limit, 
and it is entirely one-sided to only allow increases when decreases are much 
more likely to be needed in the short term.

Must the new size limit votes use 11 bytes of coinbase? Why not just use a 
numeric value pushed after height? Since this is a hardfork, I suggest 
increasing the coinbase length to allow for 100 bytes *in addition* to the 
pushed height and size-vote.

I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 MB 
(or whatever value is deemed appropriate) to make it clear that the limit 
remains a part of the consensus protocol and p2p protocol limits are not to 
have an effect on consensus rules.

Furthermore, I suggest modifying the voting to require 50% to set the limit 
floor. This has the effect of merely coordinating what miners can already 
effectively do today by rejecting blocks larger than some collusion-
determined limit.

Thoughts?

Luke