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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
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 3DF0D481
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 14:33:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
[209.85.212.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B401C1C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 14:33:16 +0000 (UTC)
Received: by wicmv11 with SMTP id mv11so60605329wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 07:33:15 -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:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=kytUwBBsA4G2K339vEXdMXsyzXau+tEBFGjtS2SuO58=;
b=P9NrS9zuQLFSZ6Zb0Ay4F5NUeqFlLIYqMQXAHNkDEcnOLdas4KybiD548rgDKUXfCK
+2q5GzxOiB2L8xQ9lerPPVZ+w4VamOP1XROw3i3K7tW44UNiAbn0f5OxMr9DqILnO1Ds
U5z8EPO98TwBMqRQr2om2I39gci4QQMn7YJ/AkMq+nT3nUdVVJ3MK13IIpzJK530gSkj
auVLZYfEaGE9HL1RzBkPNU9WNhZIxmTKn7Yl9++nqhXpdp/+6j5VKwOkFDZOnHDJ5aob
+q3cYaT6Ga24SXeYtb1IpsXtpZ6leEYvWTXtTgrcpAbEeNLLUFbCDBqhHaW3tkoOWN2P
28nw==
X-Gm-Message-State: ALoCoQn9KVPW5t0RWyqb5rJoA1vVA/h9uOSYjYzFejUoECUaYCFpO7q1MSgnUlvhsHRBBVzQLvya
MIME-Version: 1.0
X-Received: by 10.181.13.169 with SMTP id ez9mr6568263wid.92.1438353195082;
Fri, 31 Jul 2015 07:33:15 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Fri, 31 Jul 2015 07:33:14 -0700 (PDT)
In-Reply-To: <CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
Date: Fri, 31 Jul 2015 16:33:14 +0200
Message-ID: <CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <hearn@vinumeris.com>
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
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: Fri, 31 Jul 2015 14:33:18 -0000
On Fri, Jul 31, 2015 at 2:15 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> Hey Jorge,
>
>> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.
How more users or more nodes can bring more miners, or more
importantly, improve mining decentralization?
> To repeat: it's not obvious to me at all that everything wrong with Bitcoin
> can be solved by shrinking blocks. I don't think that's going to suddenly
> make everything magically more decentralised.
I don't think anybody is defending that position so you can stop refuting it.
> The 8mb cap isn't quite arbitrary. It was picked through negotiation with
> different stakeholders, in particular, Chinese miners. But it should be high
> enough to ensure organic growth is not constrained, which is good enough.
Well, negatiations don't make the number less arbitrary. As far as I
know, the sequence of events was this:
1) Gavin proposes 20MB to 20GB
2) Some chinese miners say they can securely handle at most 8 MB.
3) Gavin proposes 8 MB to 8 GB
In any case, history is irrelevant for this point: if party 1 proposes
arbitrary value A and party 2 proposes arbitrary value B, any
"compromise" value between those 2 is still an arbitrary value. For
example, A + ((B-A)/2) is still an arbitrary value.
I'm sorry, but until there's a simulation that I can run with
different sizes' testchains (for example using #6382) to somehow
compare them, I will consider any value arbitrary. A "I run this with
blocksize=X and nothing seems to have broken" doesn't help here.
We need to compare, and a criterion to compare.
>> I think it would be nice to have some sort of simulation to calculate
>> a "centralization heuristic" for different possible blocksize values
>> so we can compare these arbitrary numbers somehow.
>
>
> Centralization is not a single floating point value that is controlled by
> block size. It's a multi-faceted and complex problem. You cannot "destroy
> Bitcoin through centralization" by adjusting a single constant in the source
> code.
Agreed on the first sentence, I'm just saying that the influence of
the blocksize in that function is monotonic: with bigger sizes, equal
or worse mining centralization.
About the second sentence, yes, I could destroy Bitcoin by changing
one single constant if I could somehow force users to adopt my version
of the software. I'm sure I can actually find several examples if
necessary. "Through centralization" is harder, but say we chose
std::numeric_limits<int64_t>::max() as the maximum block size (in
practice, entirely removing the block size limit), then the consensus
rules don't have any rule to limit mining centralization.
Sacrificing that tool, and doing so this early on could certainly turn
Bitcoin into an effectively centralized system, destroying Bitcoin (or
at least the "p2p currency" part of it, which is the most interesting
one for many Bitcoin users including me).
So, once it's clear that nobody is saying that centralization depends
ONLY on the block size, can you tell us please if you think it's
useful for limiting mining centralization or not?
If you think the blocksize consensus limit does nothing to limit
centralization then there's no tradeoff to consider and you should be
consequently advocating for full removal of the limit rather than
changes towards bigger arbitrary values.
Otherwise you may want to explain why you think 8 GB is enough of a
limit to impede further centralization.
> To say once more: block size won't make much difference to how many
> merchants rely on payment processors because they aren't using them due to
> block processing overheads anyway. So trying to calculate such a formula
> won't work. Ditto for end users on phones, ditto for developers who want
> JSON/REST access to an indexed block chain, or hosted wallet services, or
> miners who want to reduce variance.
Sorry, I don't know about Pieter, but I was mostly talking about
mining centralization, certainly not about payment services.
> What people like you are Pieter are doing is making a single number a kind
> of proxy for all fears and concerns about the trend towards outsourcing in
> the Bitcoin community. Everything gets compressed down to one number you
> feel you can control, whether it is relevant or not.
No, that's not what we are doing.
It's good that you talk about your fears but, please, let other people
talk about theirs on their own.
>> > So why should anyone go through the massive hassle of setting up
>> > exchanges,
>> > without the lure of large future profits?
>>
>> Are you suggesting that bitcoin consensus rules should be designed to
>> maximize the profits of Bitcoin exchanges?
>
>
> That isn't what I said at all Jorge. Let me try again.
>
> Setting up an exchange is a lot of risky and expensive work. The motivation
> is profit, and profits are higher when there are more users to sell to. This
> is business 101.
I can imagine a non-for-profit exchange but there's no point in
finding edge cases: no general disagreement here.
> If you remove the potential for future profit, you remove the motivation to
> create the services that we now enjoy and take for granted. Because if you
> think Bitcoin can be useful without exchanges then let me tell you, I was
> around when there were none. Bitcoin was useless.
My first post on the bitcoin forums (and vague hardfork proposal, I
started reading in December 2010) was January 21, 2011 (vs yours Dec
14th 2010, as Greg pointed out in the other thread). I bought my first
bitcoins (and also sold most of them shortly after, stupid me) using
some web that used paypal and was closed down not too long after that.
At first I couldn't participate in exchanges because I had no Liberty
Reserve account...
Look, I'm sure there's many stories about how we met Bitcoin that we
can share having a beer in a bar or something. But probably most of
the subscribers to this list don't really care, and if they care they
can ask us privately, or you can create a new thread (probably better
in bitcointalk or somewhere else than here): they are completely
irrelevant in this technical discussion.
So, back on-topic: do I agree that exchanges are extremely important
for the Bitcoin ecosystem?
Yes, of course I do.
But that doesn't mean that their "potential for future profit" should
be a primary concern when deciding consensus rules changes that affect
ALL users.
But even before that, I disagree with the premise that "not rising the
consensus blocksize as soon as possible" will ruin the exchanges or
"remove their potential for future profit".
|
