summaryrefslogtreecommitdiff
path: root/18/36ffad311df19f74885ef9d3f368ec6265cfd6
blob: 7eb76f01a944fbe92b7c9ddfb54ed9fde3d5ce66 (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
Return-Path: <filipe@ktorn.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 74968AAC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 02:12:28 +0000 (UTC)
X-Greylist: delayed 00:09:31 by SQLgrey-1.7.6
Received: from laozi.macaubase.com (z83l79.static.ctm.net [202.175.83.79])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id DF99F140
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 02:12:27 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by laozi.macaubase.com (Postfix) with ESMTP id 6BFDA7C41EC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 10:02:54 +0800 (HKT)
X-Virus-Scanned: amavisd-new at macaubase.com
Received: from laozi.macaubase.com ([127.0.0.1])
	by localhost (laozi.macaubase.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id P9e0QIw36bmV
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 10:02:54 +0800 (HKT)
Received: from dmac13-2.local (nz129l231.bb122100.ctm.net [122.100.129.231])
	by laozi.macaubase.com (Postfix) with ESMTPSA id ED7E57C41EB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 10:02:53 +0800 (HKT)
Message-ID: <558A0FCB.2040908@ktorn.com>
Date: Wed, 24 Jun 2015 10:02:51 +0800
From: Filipe Farinha <filipe@ktorn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] Mempool size consensus + dynamic block size
	re-targetting
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: Wed, 24 Jun 2015 02:12:28 -0000

To my knowledge so far the main proposals regarding block size changes 
are either based on predictions, which traditionally we're not very good 
at, or a voting mechanism by a limited set of stakeholders (miners) 
whose interests may not be aligned with the rest of the community.

Neither strategy takes into account the most important factor: real-time 
changes to the mempool. This is for a valid reason, there is currently 
no consensus on the size of the mempool.

So my question is: has anyone considered the pros and cons of creating 
consensus around the current (approximate) mempool size?

I propose that, at the expense of some transaction overhead (3 or 4 
extra bytes?), each full-node that broadcasts a new transaction can add 
a mempool_size field that represents their current view of the mempool. 
As blocks are mined with this new data (which may or not be aggregated 
in the block header), all nodes can quickly reach consensus on the 
current average/median/etc mempool size, and agree on a suitable 
periodic blocksize "re-targetting" (similarly to mining difficulty).

Since all full-nodes (not just miners) get to vote with their 
transactions the consensus is truly global, and we don't have to change 
blocksize blindly in anticipation of an unpredictable future.

Would this not work, and if not, why?

Filipe Farinha