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
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <necronomics@riseup.net>) id 1Yqbqg-0000hz-Sg
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 06:33:26 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of riseup.net
designates 198.252.153.129 as permitted sender)
client-ip=198.252.153.129; envelope-from=necronomics@riseup.net;
helo=mx1.riseup.net;
Received: from mx1.riseup.net ([198.252.153.129])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Yqbqf-0008Ke-3x
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 06:33:26 +0000
Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id 1A9A44119F
for <bitcoin-development@lists.sourceforge.net>;
Fri, 8 May 2015 06:33:19 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: arkady) with ESMTPSA id F03E641FEC
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 08 May 2015 06:33:18 +0000
From: Arkady <necronomics@riseup.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <20150508000556.GA16794@savin.petertodd.org>
References: <554BE0E1.5030001@bluematt.me>
<20150508000556.GA16794@savin.petertodd.org>
Message-ID: <4726ecd29577c6271e9e9dfdc5fc2a86@riseup.net>
X-Sender: necronomics@riseup.net
User-Agent: Riseup mail
X-Virus-Scanned: clamav-milter 0.98.6 at mx1
X-Virus-Status: Clean
X-Spam-Score: -1.6 (-)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [198.252.153.129 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
X-Headers-End: 1Yqbqf-0008Ke-3x
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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: Fri, 08 May 2015 06:33:26 -0000
--[remove this line and above]--
On Thu, 7 May 2015, Gregory Maxwell wrote:
> Date: Thu, 7 May 2015 00:37:54 +0000
> From: Gregory Maxwell <gmaxwell@gmail.com>
> To: Matt Corallo <bitcoin-list@bluematt.me>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] Block Size Increase
>
> Thanks Matt; I was actually really confused by this sudden push with
> not a word here or on Github--so much so that I responded on Reddit to
> people pointing to commits in Gavin's personal repository saying they
> were reading too much into it.
I saw this. I was also pointing this out to the people who were asking
me. A
commit to a personal repository does not at first seem more than
experimental. sipa commits weird/neat things to private branches all the
time, after all.
> to share behavior. In the case of mining, we're trying to optimize the
> social good of POW security. (But the analogy applies in other ways
> too:
About the only argument IMO in favour of block size increases is to
assume
that making more room in a block will make it attractive to use for more
people at some point in the future: increasing transaction velocity,
increasing economy size, increasing value overall.
> increases to the chain side are largely an externality; miners enjoy
> the
> benefits, everyone else takes the costs--either in reduced security or
> higher node operating else.)
Who else but miners and pool operators will run full nodes when full
nodes
are being shut down because they are too large and unwieldy to maintain?
It
is already so that casual users refuse to run full nodes. This fact is
indisputable. The only question remaining is, "Do we care?" Arguments
against users who feel that the dataset is too large to run a full node,
full-time, start from a premise that these users are a static and
irrelevant
fraction. Is this even true? "Do we care?" I do. I will shortly only be
able
to run half the nodes I currently do thanks to the growth of the
blockchain
at its current rate.
> One potential argument is that maybe miners would be _regulated_ to
> behave correctly. But this would require undermining the openness of
> the
> system--where anyone can mine anonymously--in order to enforce
> behavior,
> and that same enforcement mechanism would leave a political level to
> impose additional rules that violate the extra properties of the
> system.
I would refuse to mine under such a regulated regime; moreover, I would
enjoy forking away from this, and, I suspect, the only miners who remain
would be those whose ultimate motivations do not coincide with the
users.
That is, the set of miners who are users, and the set of users who are
miners, would be wholly non-intersecting.
> So far the mining ecosystem has become incredibly centralized over
> time.
This is unfortunate but true.
> of the regular contributors to Bitcoin Core do. Many participants
> have never mined or only did back in 2010/2011... we've basically
> ignored the mining ecosystem, and this has had devastating effects,
> causing a latent undermining of the security model: hacking a dozen or
> so computers--operated under totally unknown and probably not strong
> security policies--could compromise the network at least at the tip...
The explicit form of the block dictated by the reference client and
agreed-to by the people who were sold on bitcoin near the beginning
(myself
included) was explicitly the notion that the rules were static; that the
nature of transaction foundations and the subsidies would not be
altered.
Here we have a hardfork being contemplated which is not only
controversial,
but does not even address some of the highest-utility and most-requested
features in peoples' hardfork wishlists.
The fact that mining has effectively been centralized directly implies
that
destabilizing changes that some well-heeled (and thus theoretically
capable,
at least) people have explicitly begun plans to fork the blockchain
about
will have an unknown, and completely unforeseen combined effect.
We can pretend that, "If merchants and miners and exchanges go along,
then
who else matters," but the reality is that the value in bitcoin exists
because *people* use it for real transactions: Not miners, whose profits
are
parasitically fractionally based on the quality and strength of the
bitcoin
economy as a whole; not exchanges who lubricate transactions in service
to
the economy; not even today's merchants whose primary means of accepting
bitcoin seems to be to convert them instantly to fiat and not
participate
meaningfully in the economy at all; not enriched felons; but actual
users
themselves.
> Rightfully we should be regarding this an an emergency, and probably
> should have been have since 2011.
There are two ways to look at it, assuming that the blocksize change
increases bitcoin's value to people after all: mining centralization
will be
corrected; or, mining centralization will not be corrected.
I would argue that rapidly increasing profitability at this point will
exacerbate the mining centralization problem, and in much the same way
as
when people were throwing money and unknowingly funding the massive
frauds
of the current cabals when bitcoin's exchange-driven rise to $1200 was
first
realized.
Thus, even if the premise were true, what will a blocksize increase
achieve
given mining centralization itself is a bigger systemic risk?
> Hardfork changes should only be made if they're almost completely
> uncontroversial--where virtually everyone can look at the available
> data
> and say "yea, that isn't undermining my property rights or future use
> of Bitcoin; it's no big deal".
The recent "revelation" that there are masses of paid trolls on popular
forum sites like reddit who supposedly don't even know who is hiring
them,
and the anger of more vociferous commenters in general, does not
invalidate
the relevance of every non-"industry" voice. I think elevating the
discussion away from the users does the system and the development
process
as a whole quite an injustice.
> I'm curious as to what discussions people have seen; e.g., are people
> even here aware of these concerns? Are you aware of things like the
> hashcash mediated dynamic blocksize limiting?
I have seen most of these; or the ideas seem obvious based on their
names.
> About proposals like lightning network (instant transactions and
> massive
> scale, in exchange for some short term DOS risk if a counterparty opts
> out)? Do people (other than Mike Hearn; I guess) think a future where
> everyone depends on a small number of "Google scale" node operations
> for
> the system is actually okay? (I think not, and if so we're never going
> to
> agree--but it can be helpful to understand when a disagreement is
> ideological).
It is not okay. If the current mining cabals continue to exist, and
flourish, and the developers make major changes that ignore this glaring
elephant, then the decentralized promise of bitcoin will be put more at
risk.
signmessage 1DdcrjT9Yqb6U58wVMA2e7untFbz2rmZd4
"49786791f4d0a260689867ccdfb2cc5b8460984e335504444ade113d2768505c"
G6NPl7Wklo9lcdgeVI2H2pexzgqD0KPHhI/wAe32DBm8m59Qf31j5d4tsx5drcql/8wPeIb0QGarr/o4VIOLLGE=
--[remove this line and below]--
HHsTfiZ/S7+GNYRwws+QyAr+6/MgDz0Jyntl7CAvjhdfzbnwPorybQUXxRw3CE4DgYgAy1zLanE8H/5NK+l3UlE=
|
