summaryrefslogtreecommitdiff
path: root/f6/3c90fa55692cab63392e79b9c801b02ab182e3
blob: 46325b286ba99c52be710a59d60eddbd3b589ee7 (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
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6D6F87AE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Aug 2015 23:24:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
	[209.85.212.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7DFCB1A0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Aug 2015 23:24:05 +0000 (UTC)
Received: by wicne3 with SMTP id ne3so1535910wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 05 Aug 2015 16:24:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=EK0vbdGCmyzMOfI2rxH9qhzyEZfYMco3Z7t/hToolK4=;
	b=hexP7VmCN1u/23mDotB/x8CJGczx6Fm16Nv76GGTJU2z8HP/3Kw9mMcvGmlPH7VqSf
	84jUS0ljiqz9LGbRcjTsiM2aIur1PcYtsj6YICUEhLxPccWD9lY5t8FTGGxNCUTuJORb
	ywzXNjMENK8i3KfO1PDT8MW2YY9XwWQcN1JAaZzDfUcfLF4xl8afZ3unHVlIZw61trCj
	HmeSa6C1yb7T0jL29L640pIuzS0/2sJx2EaL8IQzXj7cfqXDXpfYy1dxchcuDWe1gYtU
	2jeBUukJdSstLg4IjXtwa104HUiGrlEOUSbbsEo5uU7qdL+w/16Px15D81Y08KdvHvQh
	qyEg==
X-Gm-Message-State: ALoCoQm9XlUhTmuWadW0xUyefc8ch/6Hi80spl8/UKSgcG6TMo5nWcA747ZJh3JCTsxfN/g0VnUi
MIME-Version: 1.0
X-Received: by 10.181.13.195 with SMTP id fa3mr375868wid.7.1438817043803; Wed,
	05 Aug 2015 16:24:03 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Wed, 5 Aug 2015 16:24:03 -0700 (PDT)
Date: Thu, 6 Aug 2015 01:24:03 +0200
Message-ID: <CABm2gDoF41_1g25F-+ujohGTTFPAZJCX+Xg1QPvt=jYijvb32g@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Subject: [bitcoin-dev] Superluminal communication and the consensus block
	size limit
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, 05 Aug 2015 23:24:06 -0000

There is a common meme that block propagation times is the only metric
that matters when it comes to value the block size maximum consensus
rule's usefulness in limiting mining centralization.
Here is an extremely optimist thought experiment for those who think
that is the case:

Imagine that superluminal communication has somehow been invented and
validity of mined blocks can be checked in constant time thanks to
some sort of snarks magic. This doesn't mean that block propagation is
O(1) with respect to time because each node needs to repeat that cheap
validation before relaying the block.
Still, this is the best situation we can imagine with respect to block
propagation, right?
No, wait, due to some technical or economical miracle this
superluminal communication is free for everyone:
better-than-physically-possible (our understanding of physics changes
with time as well, right?) communication and infinite bandwidth for
everyone.

At this point, does the consensus block size maximum still help
limiting mining centralization or we can just remove it entirely?
The answer is yes, it can help limit mining centralization.

Let's imagine that these amazing advancements have happened in less
than 22 years and we only had 6 more subsidy halvings, that's only 7
halvings in total, so the subsidy is still as high as 50 * (0.5 ^ 7) =
0.390625 btc/block

Although the orphan-block-probability cost for a miner to include an
extra transaction has been completely minimized, it is still not null.
Let's assume that while all these technical miracles were
happening...that 22 more years was enough for miners to realize this
fact, they have removed the special-cased-for-free-transaction policy
code that currently comes with Bitcoin Core (or it has been removed
from Bitcoin Core) and they don't mine transactions with fees lower
than 1 satoshi anymore.
<sarcasm>I hope this last assumption doesn't turn out to be more wild
than superluminal communication...</sarcasm>

But there must be a physical limit: in our example, miners will have
different CPU constraints (to further simplify, genetically-engineered
and super-fast memory also grows in the streets everywhere after an
accident in a Monsanto Lab; or better downloadmoreram.com actually
works and I just hadn't tried from windows or mac).

Miner A is able to process 100 M tx/block while miner B is only able
to process 10 M tx/block.

Will miner B be able to maintain itself competitive against miner B?

The answer is: it depends on the consensus maximum block size.
How so? Let's imagine that it has been completely removed.

Assuming a fee of 1 satoshi per transaction and no shortage of
unconfirmed transactions, miner A's block reward will be 0.390625 + 1
= 1.390625 btc vs miner B's 0.390625 + 0.1 = 0.390625 + 0.1 = 0.490625
btc.

Difficulty will tend to increase until the cost to produce a block
(including interest in all the capital needed, paid or not) is equal
to 1.390625 btc and therefore miner B will stop mining or go bankrupt.
But maybe 100 M and 10 M were too high numbers. What about 10 M and 1
M? Still, 0.400625 btc can't compete with 0.490625 btc.
You think 10x is too much of a difference? Fine, 2M vs 1M: still
0.400625 btc can't compete with 0.410625 btc

In summary, there will always be some physical limitation that may
benefit big mining players, so the block size maximum will always be
useful to limit mining centralization.
In other words (and I don't intend this to sound rude), if you want to
eventually remove the block size maximum consensus rule entirely, I
will never be able to agree with you: not even in your wildest dreams.