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
|
Return-Path: <mruddybtc@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 82E6D88B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Aug 2015 13:57:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f195.google.com (mail-io0-f195.google.com
[209.85.223.195])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1549C115
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Aug 2015 13:57:56 +0000 (UTC)
Received: by ioeo62 with SMTP id o62so11473105ioe.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 03 Aug 2015 06:57:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=ChsgeDtS0sA2Qn+Ef8hEaf9OYoXZCeeUuXyPfyidTxI=;
b=PiyXn3my/neAMoRala3NopBCw2VJX9NDa5K0Z0m8X6c9CFRZ71M+v32aysN+ruw+GM
17CTv9Ji0/cI3v5hfonTZNiSmLoQmkWFJsid/xZrNgH6/Gvun24pPGzfGnAqGItfn56d
Jl031fL9TMZq8hVGoX5mCe+hvxK+uBkXEX8q6Y7iWhMk0QP56x/P/t8/qwcmVQiveiyu
EyKjfX6umqt73oxNb//oCrnevt98fcdNSRuFBx5F/9dsLAH/9SiGs4yVFxxgVK/8IFZ+
XA7XrpRbags6UA+0cLmp7v7zczYFeNFBEFttv3F4qIJOS145ppRAbtJLebjzyJMZgogc
B9Qg==
MIME-Version: 1.0
X-Received: by 10.107.33.65 with SMTP id h62mr22431498ioh.11.1438610275461;
Mon, 03 Aug 2015 06:57:55 -0700 (PDT)
Received: by 10.107.24.198 with HTTP; Mon, 3 Aug 2015 06:57:55 -0700 (PDT)
In-Reply-To: <CALqxMTEMajz6oHnGvocxy=xDFMBc1LaX1iWYM=w1PF0rH3syFg@mail.gmail.com>
References: <CANe1mWxsAPzWut_gDqe4R-SkDPBYM392NzeVqbUzjwh+pydsWQ@mail.gmail.com>
<CALqxMTEMajz6oHnGvocxy=xDFMBc1LaX1iWYM=w1PF0rH3syFg@mail.gmail.com>
Date: Mon, 3 Aug 2015 09:57:55 -0400
Message-ID: <CABFP+yP4-_XugCxNsUJ7eY=ATr-5bN4CdN5q8GuTjG7NWW4eMg@mail.gmail.com>
From: Michael Ruddy <mruddybtc@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A reason we can all agree on to increase 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: Mon, 03 Aug 2015 13:57:56 -0000
Does that not sound like a useful check-and-balance? It does to me.
In a scenario where these network limitations and miner rate
distributions are the same to begin, and the block and transaction
size limits are raised or removed, your observation would seem to
indicate that blocks that are outstandingly large would not be mined
often or at all (due to orphan risk), until at least the network
limitations or rate distributions changed.
Such a scenario could shape up to be a non-event. Miner majority could
choose to not change their policy regarding effective block and
transaction sizes (which includes both the size of the blocks they
create and the size of the blocks that they choose to build upon). To
make it not a total non-event, then the miners might update their
policy to increase the effective sizes a measured amount. They
wouldn't want to go too far because of the risk of spooking the
economic majority, or because of their own technological limitations
(which I'm supposing would remain transport layer limitations).
To me, in absence of these transport layer limitations that have crept
up into the consensus rules layer (clear layer violations), it seems
that one thing that would otherwise naturally bound the upper and
lower limits of effective block and transaction size is the economic
majority feedback loop to miners. Get too far out of line and the
effect on usefulness, or properties of the system, will make people
react by lowering the purchasing power of the block rewards. For
example, attack other miners to drive more mining centralization, or
create blocks that are currently too big for people to validate/use,
and that feedback loop will start to direct negatively.
Why do miners not currently choose policy that favors smaller blocks
and transactions than they do? Laziness/indifference only explains so
much. I submit that they don't because if they make the system less
useful, then people will react by selling off coins and potentially
leaving the ecosystem (they might also just wait on the sidelines to
see if the system self-corrects). If the miners tested those waters,
and found out that they made a mistake, at least they would be free to
correct their actions (and quickly). Not all would be lost. Some value
could be (temporarily) lost. It could also be re-gained if the system
self-corrected.
To follow-up on the layer violation idea that I started on before, I
think a secondary, non-consensus rule layer, indication of what block
and transaction sizes are acceptable to the economic majority would be
found in the transport protocols that they use. For example, the
effective P2P protocol limit that is 2MB or 32MB (depending on version
of the Core client) would be one such indication. Doesn't anyone think
that separating the consensus layer rules from the transport layer
supporting it should be a goal?
On Mon, Aug 3, 2015 at 2:34 AM, Adam Back via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> If block-sizes are increased in a way detrimental to the Chinese miners, it
> is not the Chinese miners that lose, it is all of the non-Chinese miners -
> this is because the Chinese miners have the slight majority of the hashrate.
> The relatively low external bandwidth connecting China to the net is
> actually the problem of the non-Chinese miners problem. Non Chinese miners
> will experience higher orphan rate once Chinese miners cease to build on top
> of blocks that are too large to sync in a timely fashion into China.
>
> Adam
|
