Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.169 as permitted sender)
	client-ip=209.85.217.169; envelope-from=pieter.wuille@gmail.com;
	helo=mail-lb0-f169.google.com; 
MIME-Version: 1.0
In-Reply-To: <554A91BE.6060105@bluematt.me>
References: <554A91BE.6060105@bluematt.me>
Date: Thu, 7 May 2015 05:47:16 +0200
Message-ID: <CAPg+sBgKqsb7NRj4kxbqkbhJac12GeOMY-oJbZyS1zZMuDhA4g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=001a11346326916f47051575c45c
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

--001a11346326916f47051575c45c
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list@bluematt.me>
wrote:

> Recently there has been a flurry of posts by Gavin at
> http://gavinandresen.svbtle.com/ which advocate strongly for increasing
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>

Thanks for bringing this up. I'll try to keep my arguments brief, to avoid
a long wall of text. I may be re-iterating some things that have been said
before, though.

I am - in general - in favor of increasing the size blocks: as technology
grows, there is no reason why the systems built on them can't scale
proportionally. I have so far not commented much about this, in a hope to
avoid getting into a public debate, but the way seems to be going now,
worries me greatly.

* Controversial hard forks. I hope the mailing list here today already
proves it is a controversial issue. Independent of personal opinions pro or
against, I don't think we can do a hard fork that is controversial in
nature. Either the result is effectively a fork, and pre-existing coins can
be spent once on both sides (effectively failing Bitcoin's primary
purpose), or the result is one side forced to upgrade to something they
dislike - effectively giving a power to developers they should never have.
Quoting someone: "I did not sign up to be part of a central banker's
committee".

* The reason for increasing is "need". If "we need more space in blocks" is
the reason to do an upgrade, it won't stop after 20 MB. There is nothing
fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Changetip does not put their microtransactions on the chain, not with 1 MB,
and I doubt they would with 20 MB blocks. The reason for increase should be
"because we choose to accept the trade-offs".

* Misrepresentation of the trade-offs. You can argue all you want that none
of the effects of larger blocks are particularly damaging, so everything is
fine. They will damage something (see below for details), and we should
analyze these effects, and be honest about them, and present them as a
trade-off made we choose to make to scale the system better. If you just
ask people if they want more transactions, of course you'll hear yes. If
you ask people if they want to pay less taxes, I'm sure the vast majority
will agree as well.

* Miner centralization. There is currently, as far as I know, no technology
that can relay and validate 20 MB blocks across the planet, in a manner
fast enough to avoid very significant costs to mining. There is work in
progress on this (including Gavin's IBLT-based relay, or Greg's block
network coding), but I don't think we should be basing the future of the
economics of the system on undemonstrated ideas. Without those (or even
with), the result may be that miners self-limit the size of their blocks to
propagate faster, but if this happens, larger, better-connected, and more
centrally-located groups of miners gain a competitive advantage by being
able to produce larger blocks. I would like to point out that there is
nothing evil about this - a simple feedback to determine an optimal block
size for an individual miner will result in larger blocks for better
connected hash power. If we do not want miners to have this ability, "we"
(as in: those using full nodes) should demand limitations that prevent it.
One such limitation is a block size limit (whatever it is).

* Ability to use a full node. I very much dislike the trend of people
saying "we need to encourage people to run full nodes, in order to make the
network more decentralized". Running 1000 nodes which are otherwise unused
only gives some better ability for full nodes to download the block chain,
or for SPV nodes to learn about transactions (or be Sybil-attacked...).
However, *using* a full node for validating your business (or personal!)
transactions empowers you to using a financial system that requires less
trust in *anyone* (not even in a decentralized group of peers) than
anything else. Moreover, using a full node is what given you power of the
systems' rules, as anyone who wants to change it now needs to convince you
to upgrade. And yes, 20 MB blocks will change people's ability to use full
nodes, even if the costs are small.

* Skewed incentives for improvements. I think I can personally say that I'm
responsible for most of the past years' performance improvements in Bitcoin
Core. And there is a lot of room for improvement left there - things like
silly waiting loops, single-threaded network processing, huge memory sinks,
lock contention, ... which in my opinion don't nearly get the attention
they deserve. This is in addition to more pervasive changes like optimizing
the block transfer protocol, support for orthogonal systems with a
different security/scalability trade-off like Lightning, making full
validation optional, ... Call me cynical, but without actual pressure to
work on these, I doubt much will change. Increasing the size of blocks now
will simply make it cheap enough to continue business as usual for a while
- while forcing a massive cost increase (and not just a monetary one) on
the entire ecosystem.

* Fees and long-term incentives. I put this last, not because I don't think
it is not serious, but because I don't understand nearly enough about it.
I'll let others comment.

I don't think 1 MB is optimal. Block size is a compromise between
scalability of transactions and verifiability of the system. A system with
10 transactions per day that is verifiable by a pocket calculator is not
useful, as it would only serve a few large bank's settlements. A system
which can deal with every coffee bought on the planet, but requires a
Google-scale data center to verify is also not useful, as it would be
trivially out-competed by a VISA-like design. The usefulness needs in a
balance, and there is no optimal choice for everyone. We can choose where
that balance lies, but we must accept that this is done as a trade-off, and
that that trade-off will have costs such as hardware costs, decreasing
anonymity, less independence, smaller target audience for people able to
fully validate, ...

Choose wisely.

Thanks for reading this,

-- 
Pieter

--001a11346326916f47051575c45c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <span dir=3D=
"ltr">&lt;<a href=3D"mailto:bitcoin-list@bluematt.me" target=3D"_blank">bit=
coin-list@bluematt.me</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Recently there has been a flurry of posts by Gavin at<br>
<a href=3D"http://gavinandresen.svbtle.com/" target=3D"_blank">http://gavin=
andresen.svbtle.com/</a> which advocate strongly for increasing<br>
the maximum block size. However, there hasnt been any discussion on this<br=
>
mailing list in several years as far as I can tell.<br></blockquote><div><b=
r></div><div>Thanks for bringing this up. I&#39;ll try to keep my arguments=
 brief, to avoid a long wall of text. I may be re-iterating some things tha=
t have been said before, though.<br><br></div><div>I am - in general - in f=
avor of increasing the size blocks: as technology grows, there is no reason=
 why the systems built on them can&#39;t scale proportionally. I have so fa=
r not commented much about this, in a hope to avoid getting into a public d=
ebate, but the way seems to be going now, worries me greatly.<br><br></div>=
<div>* Controversial hard forks. I hope the mailing list here today already=
 proves it is a controversial issue. Independent of personal opinions pro o=
r against, I don&#39;t think we can do a hard fork that is controversial in=
 nature. Either the result is effectively a fork, and pre-existing coins ca=
n be spent once on both sides (effectively failing Bitcoin&#39;s primary pu=
rpose), or the result is one side forced to upgrade to something they disli=
ke - effectively giving a power to developers they should never have. Quoti=
ng someone: &quot;I did not sign up to be part of a central banker&#39;s co=
mmittee&quot;.<br><br></div><div>* The reason for increasing is &quot;need&=
quot;. If &quot;we need more space in blocks&quot; is the reason to do an u=
pgrade, it won&#39;t stop after 20 MB. There is nothing fundamental possibl=
e with 20 MB blocks that isn&#39;t with 1 MB blocks. Changetip does not put=
 their microtransactions on the chain, not with 1 MB, and I doubt they woul=
d with 20 MB blocks. The reason for increase should be &quot;because we cho=
ose to accept the trade-offs&quot;.<br><br></div><div>* Misrepresentation o=
f the trade-offs. You can argue all you want that none of the effects of la=
rger blocks are particularly damaging, so everything is fine. They will dam=
age something (see below for details), and we should analyze these effects,=
 and be honest about them, and present them as a trade-off made we choose t=
o make to scale the system better. If you just ask people if they want more=
 transactions, of course you&#39;ll hear yes. If you ask people if they wan=
t to pay less taxes, I&#39;m sure the vast majority will agree as well.<br>=
<br></div><div>* Miner centralization. There is currently, as far as I know=
, no technology that can relay and validate 20 MB blocks across the planet,=
 in a manner fast enough to avoid very significant costs to mining. There i=
s work in progress on this (including Gavin&#39;s IBLT-based relay, or Greg=
&#39;s block network coding), but I don&#39;t think we should be basing the=
 future of the economics of the system on undemonstrated ideas. Without tho=
se (or even with), the result may be that miners self-limit the size of the=
ir blocks to propagate faster, but if this happens, larger, better-connecte=
d, and more centrally-located groups of miners gain a competitive advantage=
 by being able to produce larger blocks. I would like to point out that the=
re is nothing evil about this - a simple feedback to determine an optimal b=
lock size for an individual miner will result in larger blocks for better c=
onnected hash power. If we do not want miners to have this ability, &quot;w=
e&quot; (as in: those using full nodes) should demand limitations that prev=
ent it. One such limitation is a block size limit (whatever it is).<br><br>=
</div><div>* Ability to use a full node. I very much dislike the trend of p=
eople saying &quot;we need to encourage people to run full nodes, in order =
to make the network more decentralized&quot;. Running 1000 nodes which are =
otherwise unused only gives some better ability for full nodes to download =
the block chain, or for SPV nodes to learn about transactions (or be Sybil-=
attacked...). However, *using* a full node for validating your business (or=
 personal!) transactions empowers you to using a financial system that requ=
ires less trust in *anyone* (not even in a decentralized group of peers) th=
an anything else. Moreover, using a full node is what given you power of th=
e systems&#39; rules, as anyone who wants to change it now needs to convinc=
e you to upgrade. And yes, 20 MB blocks will change people&#39;s ability to=
 use full nodes, even if the costs are small. <br><br></div><div>* Skewed i=
ncentives for improvements. I think I can personally say that I&#39;m respo=
nsible for most of the past years&#39; performance improvements in Bitcoin =
Core. And there is a lot of room for improvement left there - things like s=
illy waiting loops, single-threaded network processing, huge memory sinks, =
lock contention, ... which in my opinion don&#39;t nearly get the attention=
 they deserve. This is in addition to more pervasive changes like optimizin=
g the block transfer protocol, support for orthogonal systems with a differ=
ent security/scalability trade-off like Lightning, making full validation o=
ptional, ... Call me cynical, but without actual pressure to work on these,=
 I doubt much will change. Increasing the size of blocks now will simply ma=
ke it cheap enough to continue business as usual for a while - while forcin=
g a massive cost increase (and not just a monetary one) on the entire ecosy=
stem.<br><br></div><div>* Fees and long-term incentives. I put this last, n=
ot because I don&#39;t think it is not serious, but because I don&#39;t und=
erstand nearly enough about it. I&#39;ll let others comment.<br><br></div><=
div>I don&#39;t think 1 MB is optimal. Block size is a compromise between s=
calability of transactions and verifiability of the system. A system with 1=
0 transactions per day that is verifiable by a pocket calculator is not use=
ful, as it would only serve a few large bank&#39;s settlements. A system wh=
ich can deal with every coffee bought on the planet, but requires a Google-=
scale data center to verify is also not useful, as it would be trivially ou=
t-competed by a VISA-like design. The usefulness needs in a balance, and th=
ere is no optimal choice for everyone. We can choose where that balance lie=
s, but we must accept that this is done as a trade-off, and that that trade=
-off will have costs such as hardware costs, decreasing anonymity, less ind=
ependence, smaller target audience for people able to fully validate, ...<b=
r><br></div><div>Choose wisely.<br><br></div><div>Thanks for reading this,<=
br><br></div><div>-- <br></div><div>Pieter<br><br></div></div></div></div>

--001a11346326916f47051575c45c--