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
|
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 AD0D0308
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 18:56:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com
[209.85.212.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8FCBE8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 18:56:24 +0000 (UTC)
Received: by widfa3 with SMTP id fa3so3946072wid.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 11:56:23 -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=aa6c7nuL4qSjLxyr9fc2Q54GMsuaMSr/mevvuOZLYY0=;
b=XnVsyKm4Abec4DDphI4n3Paiq/VOy9GlYcSVwlYjFnCyyj4pT91gBWBId0IsNXSTAo
k4UWkFzIaAiS/HPieRnf605P4yMTItu/o+lnqgn/qB1gocLnzgAA7T05lENwGBoLkFGN
CXMjEs3cWza1IrhggA0Aaai4EXymsgqmURJPy4JTG0hh8NL7tRzKPf0olriLvBE37zTg
UxtHS7+JipKZgjmLL6n90JgCqD0sBhSwJH614hck4wU28ldxEDbxVj8ALalWPRi70R7+
c7GiEMfI9oC3VFWgpC7clO/HbmpoH/2HXOoU++uMq977zzytXdsAfbGD6TLDBGykKwjm
ugew==
X-Gm-Message-State: ALoCoQnqoZ3ATHt/VoR/f7t/X6bP+V8uc5Xt6sKZ/DN5bLSNAliITB7s6a7ty0ONKRhfEPVHe5jG
MIME-Version: 1.0
X-Received: by 10.180.39.136 with SMTP id p8mr8241991wik.92.1440960983111;
Sun, 30 Aug 2015 11:56:23 -0700 (PDT)
Received: by 10.194.64.234 with HTTP; Sun, 30 Aug 2015 11:56:22 -0700 (PDT)
In-Reply-To: <8faa4df0135b558e5cd064ccaec09e73@xbt.hk>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
<CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
<2081355.cHxjDEpgpW@crushinator>
<A30CC2E3-A769-445C-95A2-35B963EFC283@gmail.com>
<CAB+qUq7ZzLHrFZ5FQazrcALA-b-jFh_bf-XX1GaJbGY1KQB5YA@mail.gmail.com>
<CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>
<CABm2gDreJ1PwZu3WgZdj_RR0W9JoQTF9w-Qwyfoh6uk1EM0ajg@mail.gmail.com>
<CAOG=w-uYFbyUF+PZABNvMqHei2-yuoCETtXnfkYV-Rr9-pPKuw@mail.gmail.com>
<CADJgMzvJDSk6oZMZPc4C8ENHhGvspdeF7WURfnY6OPKWs33a7w@mail.gmail.com>
<CABm2gDo66UzhLU3Dgc6Cj=0Au4xJNv-U9GUv8JaryakQFJ=VQA@mail.gmail.com>
<8faa4df0135b558e5cd064ccaec09e73@xbt.hk>
Date: Sun, 30 Aug 2015 20:56:22 +0200
Message-ID: <CABm2gDp=1XHzyXF=JbVLWzfyuFKSnbMbDwLk_2NpWq5s3vukpA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: jl2012@xbt.hk
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] Consensus based block size retargeting algorithm
(draft)
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: Sun, 30 Aug 2015 18:56:25 -0000
On Sun, Aug 30, 2015 at 7:13 PM, <jl2012@xbt.hk> wrote:
> This is based on the assumption that miners would always like to use up the
> last byte of the available block size. However, this is just not true:
>
> 1. The 6 year blockchain history has shown that most miners have a soft cap
> with their block size.
>
> 2. Chinese miners, controlling 60% of the network, rejected Gavin's initial
> 20MB proposal and asked for 8MB:
> http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
> [...]
No, I'm not making such assumption. I'm focusing on what they CAN do,
while suspending judgement on their good will and not trying to
predict their future behavior from historic behaviour.
With 60% of the hashrate, you can easily get 100% by orphaning
everybody else's blocks. More importantly, being under the same
jurisdiction they can be forced to behave in certain way (for example,
censor transactions) by law.
I'm very worried about the current situation no matter how benevolent
current miners are. Thus weakening the only limit to mining
centralization that we have at the consensus rule level seems
extremely risky at this point.
> For many reasons miners may want to have a smaller block size, which we
> don't need to list them here. Although they can limit it by a softfork or
> even 51% attack, it is a very violent process. Why don't we just allow them
> to vote for a lower limit?
>
> So I think the right way is to choose a mining-centralization-safe limit,
> and let it free float within a range based on miner's vote. If we are lucky
> enough to have some responsible miners, they will keep it as low as
> possible, until the legitimate tx volume catches up. Even in the worst case,
> the block size is still mining-centralization-safe. The upper limit may
> increase linearly, if not exponentially, until we find a better long-term
> solution. (sort of a combination of BIP100 and 101, with different
> parameters)
My point is, a "soft cap" determined by miners clearly doesn't protect
us from mining centralization: the "hard cap" does.
Knowing that, and given that miners can currently set their own policy
block size maximum, what does this "voting on a lower limit" achieve?
What are the gains? Why are we "lucky" if they keep the lower one as
low as possible?
> For the matter of "urgency", I agree with you that there is no actual
> urgency AT THIS MOMENT. However, if a hardfork may take 5 years to deploy
> (as you suggested), we really have the urgency to make a decision now.
Thank you for admitting it is not urgent!
I suggested 5 years for the concrete hardfork in bip99 because it's
clearly non-urgent and I wanted to be very conservative. I'm happy to
reduce that to say, 1 year (specially given that the change is very
simple to implement).
For a simple block size change (like, say bip102) 1 year (maybe 6
months + miner's confirmation) is probably more than enough as well.
And we can always deploy an urgency hardfork if it is necessary.
> Actually, the main point is not urgency but uncertainty. We have debated for
> 5 years. Why won't we have 5 more years of debate, plus 5 years of
> deployment delay? Are we sticking to 1MB for 10 years? In that case Bitcoin
> Core must be abandoned by the economic majority and a Schism fork must
> occur.
Fortunately we haven't been discussing this for 5 years, I don't know
where you get that from.
A schism fork it's certainly always a possibility but I would only
consider it after an urgency hardfork (once the issue becomes urgent)
fails due to not being uncontroversial.
Would you agree with me on that?
What would be your criterion for considering an increase in block size urgent?
Mine is: we should consider a block increase only when minimum market
fees for transactions to be mined (currently zero satoshis) increase
above a high fee (admittedly undefined, but certainly greater than
zero).
Even if it's "urgent", I think we should only increase the maximum if,
at the same time, the new size can be considered safe
mining-centralization-wise (unfortunately we don't have any metric to
measure that nor enough tools to realistically simulate different
sizes in different network topologies at the moment). But once we have
them, the next discussion will be much simpler, so I don't see the
need for block size maximum that changes over time (neither
exponentially nor linearly).
Would you agree with me that mining centralization should be the most
important criterion when changing the block size maximum rule rather
than the level of minimum fees?
If the community can't agree on this, I'm afraid there will be a
schism hardfork eventually. Another possibility is that those who
aren't concerned with mining centralization start their own altcoin
(centralizedcoin? ), maybe a spinoff [
https://bitcointalk.org/index.php?topic=563972.0 ] if they want to
keep Bitcoin's utxo at the moment of the separation.
But if the community agrees with this and just disagrees on the
maximum block size consensus rule having any effect on mining
centralization (like Gavin and I disagree), we should calm down and
use scientific processes to find out what the relation between the two
actually is (if there's any relation at all).
Would you agree with me on this?
|
