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
|
Return-Path: <nbvfour@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 638671234
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 03:18:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com
[209.85.223.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D16EE87
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 03:18:13 +0000 (UTC)
Received: by mail-io0-f170.google.com with SMTP id o67so268538036iof.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Dec 2015 19:18:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:date:message-id:subject:from:to:content-type;
bh=CeLcu8UTSAwaUhIT0f1v40nLpi1m6ICXGta8lNPU13Y=;
b=rjXAL5iC/xXq5iT6HnPLCNskDRoRGE5Tnz8euf6LxEeNSrm2JQlURKNdWUPgX9Be/e
OvccfQN0hF8itwW6rrUN/5XPA92tLoVFdVS6/CSE68UvO/zj4gNOEvt2f7gPDp8XI4P7
yBXFYnS2/Pj/z+k0LZL2vVQVH5okKCNKM5eRZgRy7Gtw/QIbcc+YgWtGJClHjr39P+gM
Kd94DG5kMoQm8nMzzvRlucYWYPznqqqvgLpW9JSvAfbbXYWuhNr4kWDVAKtXNwil0sBF
ZmJSt3S0mH2TKGKpmzahYiApw1VJzEiVFHGTv5R7P9j7zSdJVJlJlA8VrPnXSlwAHpPM
DoTQ==
MIME-Version: 1.0
X-Received: by 10.107.13.143 with SMTP id 137mr41577297ion.72.1451099893326;
Fri, 25 Dec 2015 19:18:13 -0800 (PST)
Sender: nbvfour@gmail.com
Received: by 10.36.20.142 with HTTP; Fri, 25 Dec 2015 19:18:13 -0800 (PST)
Date: Fri, 25 Dec 2015 19:18:13 -0800
X-Google-Sender-Auth: jUCQ-7t0INFsYGWF13BhCjk2rOc
Message-ID: <CAAcC9yuC1ouEP4h3_9Btj3289+KeC8abPx5trzyergca-9BHYQ@mail.gmail.com>
From: Chris Priest <cp368202@ohiou.edu>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_05,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, 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] "Hashpower liquidity" is more important than "mining
centralization"
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: Sat, 26 Dec 2015 03:18:14 -0000
The term "mining centralization" is very common. It come up almost in
every single discussion relating to bitcoin these days. Some people
say "mining is already centralized" and other such things. I think
this is a very bad term, and people should stop saying those things.
Let me explain:
Under normal operations, if every single miner in th network is under
one roof, nothing would happen. If there was oly one mining pool that
everyone had to use, this would have no effect on the system
whatsoever. The only time this would be a problem is if that one pool
were to censor transactions, or in any other way operate out of the
normal.
Right now, the network is in a period of peace. There are no
governments trying to coerce mining pools into censoring transaction,
or otherwise disrupting the network. For all we know, the next 500
years of bitcoin's history could be filled with complete peaceful
operations with no government interference at all.
*If* for some reason in the future a government were to decide that
they want to disrupt the bitcoin network, then all the hashpower being
under one control will be problematic, if and only if hashpower
liquidity is very low. Hashpower liquidity is the measure of how
easily hashpower can move from one pool to another. If all the mining
hardware on the network is mining one one pool and **will never or can
never switch to another pool** then the hashpower liquidity is very
low. If all the hashpower on the network can very easily move to
another pool, then hashpower liquidity is very high.
If the one single mining pool were to start censoring transactions and
there is no other pool to move to, then hashpower liquidity is very
high, and that would be very bad for bitcoin. If there was dozens of
other pools in existence, and all the mining hardware owners could
switch to another pool easiely, then the hashpower liquidity is very
high, and the censorship attack will end as soon as the hashpower
moves to other pools.
My argument is that hashpower liquidity is much more important of a
metric to think about than simply "mining centralization". The
difference between the two terms is that one term describes a
temporary condition, while the other one measures a more permanent
condition. Both terms are hard to measure in concrete terms.
Instead of saying "this change will increase mining centralization" we
should instead be thinking "will this change increase hashpower
liquidity?".
Hopefully people will understand this concept and the term "mining
centralization" will become archaic.
|
