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
|
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 843ED3C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 11:51:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADD0A7C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 11:51:05 +0000 (UTC)
Received: by wicmv11 with SMTP id mv11so55124846wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 04:51: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:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=OsTiQgbevT7zDmtYHdQJW/MgF9t62xO/gkx2t+tVZ68=;
b=SJ6IcUYkxEQqXLhVmaomCphVDLGW3TDAdVtZqDyeN9fhcZm7XgV1wIlHAOnzGsWy5X
+jIFMaG46uwX5V3WflBh5js7JDQO0XYlnCw2pbaCoLsXSR452iOxabGfXvLAW2sU69aJ
XkDLao+ymbeUflTkE63yndVIg70oFWjPL054ZKmbu+oogc6fvbToEEAbb9XEyrlHSseU
ar8WtAAlmWAezc1wPiZio3puUQcZ6YFBjxdtGxX4tIUZ/0hIGe+61r5Lc6++B4MaP/q8
gpUeR9wjZKBCYPpxpoWsShAOD08OUNYR4VS86L3PhD+LULgDDi/zPJh3KNFjcHjOHWnP
rO2Q==
X-Gm-Message-State: ALoCoQk5Nn3WLWBCvt74uHGxyiIqQ40AgNYNcNZH8wyz9wQkkms0khM35UBMOTrATPwLE8OiRO+y
MIME-Version: 1.0
X-Received: by 10.180.109.106 with SMTP id hr10mr6375725wib.58.1438343464314;
Fri, 31 Jul 2015 04:51:04 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Fri, 31 Jul 2015 04:51:04 -0700 (PDT)
In-Reply-To: <CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@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>
Date: Fri, 31 Jul 2015 13:51:04 +0200
Message-ID: <CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@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 11:51:06 -0000
On Fri, Jul 31, 2015 at 12:16 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Well, centralization of mining is already terrible. I see no reason why we
>> should encourage making it worse.
>
> I see constant assertions that node count, mining centralisation, developers
> not using Bitcoin Core in their own businesses etc is all to do with block
> sizes. But nobody has shown that. Nobody has even laid the groundwork for
> that. Verifying blocks takes milliseconds and downloading them takes seconds
> everywhere except, apparently, China: this resource usage is trivial.
He is not saying that. Whatever the reasons for centralization are, it
is obvious that increasing the size won't help.
In the best case, it will only make it slightly worse. How big of a
"slightly worse" are we willing to risk to increase the size is the
open question.
> So I see no reason why arbitrarily capping the block size will move the
> needle on these metrics. Trying to arrest the growth of Bitcoin for everyone
> won't suddenly make Bitcoin-Qt a competitive wallet, or make service devs
> migrate away from chain.com, or make merchants stop using BitPay.
As far as I know, people just want to change an arbitrary number for
another arbitrary number.
But this arbitrary cap is a cap to centralization, not a tool to make
Bitcoin-Qt more important or to attack concrete Bitcoin companies like
you seem to think.
If you don't think the blocksize cap helps limiting centralization and
you think it would be fine to completely remove it, then it would be
better for the conversation that you said that directly instead of
supporting other arbitrary caps like 8GB (bip101).
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. Even if the first
definition of this "centralization heuristic" is stupid, it would be
better than keep rolling dices and heatedly defend one result over
another.
To reiterate, If you don't think the blocksize cap helps limiting
centralization, please, say so.
If we can't agree on what the limit is for, we will never be able to
agree on whether 1MB (current situation) or 8GB (bip101) is the most
appropriate value to have at a given point in time.
>> We need to accept that, and all previous proposals I've seen don't seem to
>> do that.
>
> I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth
> you're right, some use cases will be priced out. I initiated the
> micropayment channels project (along with Matt, tip of the hat) specifically
> to optimise a certain class of transactions. Even with 8mb+ blocks, there
> will still be a need for micropayment channels, centralised exchange
> platforms and other forms of off chain transaction.
Lightning is nothing more than a better design for trustless payment
channels, but it's really good that you agree that if we want to scale
not everything can be broadcast in-chain.
>> If Bitcoin needs to support a large scale, it already failed.
>
> It hasn't even been tried.
What he means is that if Bitcoin needs to support a scale that is only
feasible with high degrees of centralization (say, supporting 1 M tx/s
right now), then it has already failed in its decentralization goals.
In fact, with only a few miners, I'm not sure regulators will still
agree Bitcoin transactions are irreversible...
But you are right, we haven't tried to destroy bitcoin by removing the
only available consensus tool to limit centralization yet.
I don't want to try, do you?
> A decentralised currency that the vast majority can't use doesn't change the
> amount of centralisation in the world. Most people will still end up using
> banks, with all the normal problems. You cannot solve a problem by creating
> a theoretically pure solution that's out of reach of ordinary people: just
> ask academic cryptographers!
Let's go to "most people use bitcoin" first and then think about "many
people ONLY use Bitcoin" later, please.
I believe everybody here thinks that the more people are able to use
Bitcoin, the better.
But that doesn't
> All the plans for some kind of ultra-throttled Bitcoin network used for
> infrequent transactions neglect to ask where the infrastructure for that
> will come from. The network of exchanges, payment processors and startups
> that are paying people to build infrastructure are all based on the
> assumption that the market will grow significantly. It's a gamble at best
> because Bitcoin's success is not guaranteed, but if the block chain cannot
> grow it's a gamble that is guaranteed to be lost.
Risking destroying Bitcoin through centralization to be able to keep
free transactions for longer it's a very risky gamble.
Doing so explicitly against the will of some of the users by promoting
schism hardfork, and thus risking to economically destroy both Bitcoin
and Bitcoin_new_size (different currencies) in the process is also a
very risky gamble.
So may want to give some example of responsibility yourself to make
these calls to responsibility more credible.
You certainly cannot know what "all the payment processors and
startups plans" are based on, and spreading conspiracy theories about
the evil secret plans of Blockstream (or any other Bitcoin company)
doesn't help in keeping this discussion civilized, contaminates
bitcoin development in general and unhealthily polarizes the whole
Bitcoin ecosystem. Also, I believe is doing a disservice to your
reputation among technical people, but since you don't seem worried
about that, why should I be?
> 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?
I assume not, but I'm really having troubles trying to read the
question with another meaning.
Can you rephrase this, please?
|
