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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YqOON-0003gS-S8
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 16:11:19 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.181 as permitted sender)
client-ip=209.85.212.181; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f181.google.com;
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqOOM-0006m2-7K
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 16:11:19 +0000
Received: by widdi4 with SMTP id di4so65887965wid.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 09:11:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.9.161 with SMTP id a1mr9068474wjb.39.1431015072198; Thu,
07 May 2015 09:11:12 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.90.114 with HTTP; Thu, 7 May 2015 09:11:11 -0700 (PDT)
In-Reply-To: <CABm2gDpgBNjuPLnFiU2TspgLws7JjWnsxih09JG9bQycraS=sQ@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
<CABm2gDpgBNjuPLnFiU2TspgLws7JjWnsxih09JG9bQycraS=sQ@mail.gmail.com>
Date: Thu, 7 May 2015 18:11:11 +0200
X-Google-Sender-Auth: eHOao9wbohyfWshNl4vHQy_poG8
Message-ID: <CANEZrP1ay64jryeUyDJ9Y+1C-Bre1U_1xMyuB4cqQprd1-qbCA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=047d7b5d34fa0bf6c60515802902
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YqOOM-0006m2-7K
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 16:11:19 -0000
--047d7b5d34fa0bf6c60515802902
Content-Type: text/plain; charset=UTF-8
>
> It is an argument against my admittedly vague definition of
> "non-controversial change".
>
If it's an argument against something you said, it's not a straw man, right
;)
Consensus has to be defined as agreement between a group of people. Who are
those people? If you don't know, it's impossible to decide when there is
consensus or not.
Right now there is this nice warm fuzzy notion that decisions in Bitcoin
Core are made by consensus. "Controversial" changes are avoided. I am
trying to show you that this is just marketing. Nobody can define what
these terms even mean. It would be more accurate to say decisions are
vetoed by whoever shows up and complains enough, regardless of technical
merit. After all, my own getutxo change was merged after a lot of technical
debate (and trolling) ..... then unmerged a day later because "it's a
shitstorm".
So if Gavin showed up and complained a lot about side chains or whatever,
what you're saying is, oh that's different. We'd ignore him. But when
someone else complains about a change they don't like, that's OK.
Heck, I could easily come up with a dozen reasons to object to almost any
change, if I felt like it. Would I then be considered not a part of the
consensus because that'd be convenient?
> I'm sure that's not what the proponents of the size increase want, and
> I'm not defending 1 MB as a sacred limit or anything, but my question
> is "where is the limit for them?"
>
20mb is an arbitrary number, just like 1mb. It's good enough to keep the
Bitcoin ecosystem operating as it presently does: gentle growth in usage
with the technology that exists and is implemented. Gavin has discussed in
his blog why he chose 20mb, I think. It's the result of some estimates
based on average network/hardware capabilities.
Perhaps one day 20mb will not be enough. Perhaps then the limit will be
raised again, if there is sufficient demand.
You are correct that "no limit at all" is a possible answer. More
precisely, in that case miners would choose. Gavin's original proposal was
20mb+X where X is decided by some incrementing formula over time, chosen to
approximate expected improvements in hardware and software. That was cool
too. The 20mb figure and the formula were an attempt to address the
concerns of people who are worried about the block size increase: a
meet-in-the-middle compromise.
Unfortunately it's hard to know what other kinds of meet-in-the-middle
compromise could be made here. I'm sure Gavin would consider them if he
knew. But the concerns provided are too vague to address. There are no
numbers in them, for example:
- We need more research -> how much more?
- I'm not against changing the size, just not now -> then when?
- I'm not wedded to 1mb, but not sure 20mb is right -> then what?
- Full node count is going down -> then what size do you think would fix
that? 100kb?
- It will make mining more centralised -> how do you measure that and
how much centralisation would you accept?
and so on.
--047d7b5d34fa0bf6c60515802902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">It is an argument against my admittedly vague de=
finition of<br>
"non-controversial change".<br></blockquote><div><br></div><div>I=
f it's an argument against something you said, it's not a straw man=
, right ;)</div><div><br></div><div>Consensus has to be defined as agreemen=
t between a group of people. Who are those people? If you don't know, i=
t's impossible to decide when there is consensus or not.</div><div><br>=
</div><div>Right now there is this nice warm fuzzy notion that decisions in=
Bitcoin Core are made by consensus. "Controversial" changes are =
avoided. I am trying to show you that this is just marketing. Nobody can de=
fine what these terms even mean. It would be more accurate to say decisions=
are vetoed by whoever shows up and complains enough, regardless of technic=
al merit. After all, my own getutxo change was merged after a lot of techni=
cal debate (and trolling) ..... then unmerged a day later because "it&=
#39;s a shitstorm".</div><div><br></div><div>So if Gavin showed up and=
complained a lot about side chains or whatever, what you're saying is,=
oh that's different. We'd ignore him. But when someone else compla=
ins about a change they don't like, that's OK.</div><div><br></div>=
<div>Heck, I could easily come up with a dozen reasons to object to almost =
any change, if I felt like it. Would I then be considered not a part of the=
consensus because that'd be convenient?</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">I'm sure that's not what the proponents of t=
he size increase want, and<br>
I'm not defending 1 MB as a sacred limit=C2=A0 or anything, but my ques=
tion<br>
is "where is the limit for them?"<br></blockquote><div><br></div>=
<div>20mb is an arbitrary number, just like 1mb. It's good enough to ke=
ep the Bitcoin ecosystem operating as it presently does: gentle growth in u=
sage with the technology that exists and is implemented. Gavin has discusse=
d in his blog why he chose 20mb, I think. It's the result of some estim=
ates based on average network/hardware capabilities.</div><div><br></div><d=
iv>Perhaps one day 20mb will not be enough. Perhaps then the limit will be =
raised again, if there is sufficient demand.</div><div><br></div><div>You a=
re correct that "no limit at all" is a possible answer. More prec=
isely, in that case miners would choose. Gavin's original proposal was =
20mb+X where X is decided by some incrementing formula over time, chosen to=
approximate expected improvements in hardware and software. That was cool =
too. The 20mb figure and the formula were an attempt to address the concern=
s of people who are worried about the block size increase: =C2=A0a meet-in-=
the-middle compromise.</div><div><br></div><div>Unfortunately it's hard=
to know what other kinds of meet-in-the-middle compromise could be made he=
re. I'm sure Gavin would consider them if he knew. But the concerns pro=
vided are too vague to address. There are no numbers in them, for example:<=
/div><div><ul><li>We need more research -> how much more?</li><li>I'=
m not against changing the size, just not now -> then when?</li><li>I=
9;m not wedded to 1mb, but not sure 20mb is right -> then what?</li><li>=
Full node count is going down -> then what size do you think would fix t=
hat? 100kb?</li><li>It will make mining more centralised -> how do you m=
easure that and how much centralisation would you accept?</li></ul><div>and=
so on.</div></div></div></div></div>
--047d7b5d34fa0bf6c60515802902--
|
