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
|
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 922948DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 13:37:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
[209.85.212.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A2ABB1A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 13:37:51 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so177640756wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 04 Aug 2015 06:37:50 -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
:content-transfer-encoding;
bh=2EjMJr8mwiCDBReYHOmBXZz3FpfsWgC96TNDcl+7hpc=;
b=gagQLMusbGNeG+xEmWpXhHH0ThqQpHvgXGdBerKUXYVxVAvb1Kj9QQieyyvp1PhYlL
yrI8n2Qm6mbv+10nM+ANme7A1Fvf1i4eUU0qfpETDcyIOc2dt/wb72Fni1s/YCB2tjvI
rslaq0uoLNhNXrCqlW02e5AUcW/YgIYTy6igIEhrMZebVMsbDoorf+joDAYoduoCvBrQ
93NL0XHb23upwqcOxCqyCBpG5l06O7CQAcYbA7muPXRFFuGpYOaz0jRVQEPFNF6gL1d5
3U+dlKytSvDRR8u1nlm9ggN5GAhaOUSZnKn8LtFhbCtrAJ7SmBvJVJCGTKs/tIdPS/po
sTJQ==
X-Gm-Message-State: ALoCoQlK60VAa3zAD28JJc89XHS9MYGl3gPM8jwiLvcoa1HFBLnKqR5T5MZIzXVXN1IKQIRG28CH
MIME-Version: 1.0
X-Received: by 10.180.109.106 with SMTP id hr10mr46627906wib.58.1438695470186;
Tue, 04 Aug 2015 06:37:50 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Tue, 4 Aug 2015 06:37:49 -0700 (PDT)
In-Reply-To: <CAAO2FKHJMbt2kpJy+sLTNWAgBwdxZNoEbcUsVF7rbXgbjTx4yQ@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>
<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
<CAAO2FKHJMbt2kpJy+sLTNWAgBwdxZNoEbcUsVF7rbXgbjTx4yQ@mail.gmail.com>
Date: Tue, 4 Aug 2015 15:37:49 +0200
Message-ID: <CABm2gDp+yDQ0TiruN8taZRWL-2AT48ixwA4=7MiOLJwK-+zH7A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Hector Chu <hectorchu@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Tue, 04 Aug 2015 13:37:52 -0000
On Tue, Aug 4, 2015 at 2:19 PM, Hector Chu <hectorchu@gmail.com> wrote:
> On 4 August 2015 at 12:59, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>>
>> That is not my position. Again, I don't know what the right blocksize
>> for the short term is (I don't think anybody does).
>
> You have no position (i.e. neutral). In other words, keeping the existing
> limit.
No, I think 1 MB is just as arbitrary as any other size proposed.
All I want is for consensus change proponents to try harder to
convince other users (including me)
>> Therefore how the change can affect mining centralization must be the
>> main concern, instead of (also artificial) projections about usage
>> growth (no matter how organic their curves look).
>
>
> The degree of mining decentralization is only one of many concerns. Users=
'
> main concern is timely confirmation of low-fee transactions. Miners' conc=
ern
> is the amount of profit they make.
No, if the changed rule only serves to limit centralization, then how
that limitation to centralization is affected should be the first
thing to consider.
If miners' concern was only the amount of profit they make they
wouldn't mine free transactions already.
You cannot possibly know what all users' are concern about, so I will
just ignore any further claim in that direction.
Talk for yourself: your arguments won't be more reasonable just
because you claim that all users think like you do.
>> Also I don't think "hitting the limit" must be necessarily harmful and
>> if it is, I don't understand why hitting it at 1MB will be more
>> harmful than hitting it at 2MB, 8MB or 8GB.
>
>
> The limit won't even get to be hit, because all the users that get thrown
> out of Bitcoin will have moved over to a system supporting a larger block
> size.
I disagree with this wild prediction as well.
>> I don't know where you get your "majority" from or what it even means
>> (majority of users, majority of the coins, of miners?)
>
>
> The majority which the miners are beholden to is the economic majority.
> https://en.bitcoin.it/wiki/Economic_majority
And I assume the way that vaguely defined "economic majority"
communicates with you through a crystal ball or something
>> But there's something I'm missing something there...why my position
>> doesn't matter if it's not a majority?
>
>
> Your position is only one of many and it does not carry excess weight to =
the
> others. Individually it won't matter, because you can't control the
> implementation that other people run.
No more, but not less either.
Nobody can't control the implementation that I (or other people
concerned with centralization) run either.
>> How is what the the majority has been told it's best an objective
>> argument?
>
>
> Don't fight the market. The way the system is designed, the miners will
> follow along with what the economic majority have decided.
How is allowing fees from rising above zero "fighting the market"?
The system is currently designed with a 1 MB limit. I don't think
that's sacred or anything, but I really don't feel like I'm fighting
"the market" or "the way the system is designed".
In any case, what do "the market" and "the way the system is designed"
have to do with what the majority have been told it's best (which you
seem to think should be a source of truth for some reason I'm still
missing)?
>> So if you say 8, I must ask, why not 9?
>> Why 9 MB is not safe for mining centralization but 8 MB is?
>
>
> 8MB has simply been the focal point for this debate. 9MB is also safe if =
8MB
> is, but I suppose the opponents will be even less happy with 9 than with =
8,
> and we don't want to unnecessarily increase the conflict.
Why 9 MB is safe but 10 MB isn't?
The "conflict" won't be resolved by evading hard questions...
>> It seems like the rationale it's always "the bigger the better" and
>> the only limitation is what a few people concerned with mining
>> centralization (while they still have time to discuss this) are
>> willing to accept. If that's the case, then there won't be effectively
>> any limit in the long term and Bitcoin will probably fail in its
>> decentralization goals.
>
>
> A one-time increase to 8MB is safer than a dynamically growing limit over
> time for exactly this reason. Admittedly whenever the next debate to
> increase the block size over 8MB happens it will be even more painful and
> non-obvious, but that is the safety check to prevent unbounded block size
> increase.
Will there ever be a debate that results in "further blocksize
increases at this point are very risky for mining centralization"?
How will we tell then? Can't we use the same criteria now?
|
