MIME-Version: 1.0
In-Reply-To: <CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@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>
Date: Fri, 31 Jul 2015 12:16:46 +0200
Message-ID: <CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a113eceb2054cb8051c291e9f
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Precedence: list

--001a113eceb2054cb8051c291e9f
Content-Type: text/plain; charset=UTF-8

I agree with Gavin - whilst it's great that a Blockstream employee has
finally made a realistic proposal (i.e. not "let's all use Lightning") -
this BIP is virtually the same as keeping the 1mb cap.

> Well, centralization of mining is already terrible. I see no reason why we
> should encourage making it worse.
>
Centralization of mining has been a continual gripe since Slush first
invented pooled mining. There has never been a time after that when people
weren't talking about the centralisation of mining, and back then blocks
were ~10kb.

I see constant assertions that node count, mining centralisation,
developers not using Bitcoin Core in their own businesses etc is all to do
with block sizes. But nobody has shown that. Nobody has even laid the
groundwork for that. Verifying blocks takes milliseconds and downloading
them takes seconds everywhere except, apparently, China: this resource
usage is trivial.

Yet developers, miners and users even outside of China routinely delegate
validation to others. Often for quite understandable technical reasons that
have nothing to do with block sizes.

So I see no reason why arbitrarily capping the block size will move the
needle on these metrics. Trying to arrest the growth of Bitcoin for
everyone won't suddenly make Bitcoin-Qt a competitive wallet, or make
service devs migrate away from chain.com, or make merchants stop using
BitPay.

We need to accept that, and all previous proposals I've seen don't seem to
> do that.
>
I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth
you're right, some use cases will be priced out. I initiated the
micropayment channels project (along with Matt, tip of the hat)
specifically to optimise a certain class of transactions. Even with 8mb+
blocks, there will still be a need for micropayment channels, centralised
exchange platforms and other forms of off chain transaction.

If Bitcoin needs to support a large scale, it already failed.
>
It hasn't even been tried.

The desperately sad thing about all of this is that there's going to be a
fork, and yet I think most of us agree on most things.  But we don't agree
on this.

Bitcoin can support a large scale and it must, for all sorts of reasons.
Amongst others:

   1. Currencies have network effects. A currency that has few users is
   simply not competitive with currencies that have many. There's no such
   thing as a settlement currency for high value transactions only, as
   evidenced by the ever-dropping importance of gold.


   2. A decentralised currency that the vast majority can't use doesn't
   change the amount of centralisation in the world. Most people will still
   end up using banks, with all the normal problems. You cannot solve a
   problem by creating a theoretically pure solution that's out of reach of
   ordinary people: just ask academic cryptographers!


   3. Growth is a part of the social contract. It always has been.

   The best quote Gregory can find to suggest Satoshi wanted small blocks
   is a one sentence hypothetical example about what *might* happen if
   Bitcoin users became "tyrannical" as a result of non-financial transactions
   being stuffed in the block chain. That position makes sense because his
   scaling arguments assuming payment-network-sized traffic and throwing DNS
   systems or whatever into the mix could invalidate those arguments, in the
   absence of merged mining. But Satoshi did invent merged mining, and so
   there's no need for Bitcoin users to get "tyrannical": his original
   arguments still hold.


   4. All the plans for some kind of ultra-throttled Bitcoin network used
   for infrequent transactions neglect to ask where the infrastructure for
   that will come from. The network of exchanges, payment processors and
   startups that are paying people to build infrastructure are all based on
   the assumption that the market will grow significantly. It's a gamble at
   best because Bitcoin's success is not guaranteed, but if the block chain
   cannot grow it's a gamble that is guaranteed to be lost.

   So why should anyone go through the massive hassle of setting up
   exchanges, without the lure of large future profits?


   5. Bitcoin needs users, lots of them, for its political survival. There
   are many people out there who would like to see digital cash disappear, or
   be regulated out of existence. They will argue for that in front of
   governments and courts .... some already are. And if they're going to lose
   those arguments, the political and economic damage of getting rid of
   Bitcoin must be large enough to make people think twice. That means it
   needs supporters, it needs innovative services, it needs companies, and it
   needs legal users making legal payments: as many of them as possible.

   If Bitcoin is a tiny, obscure currency used by drug dealers and a
   handful of crypto-at-any-cost geeks, the cost of simply banning it outright
   will seem trivial and the hammer will drop. There won't be a large scale
   payment network OR a high-value settlement network. And then the world is
   really screwed, because nobody will get a second chance for a very long
   time.

--001a113eceb2054cb8051c291e9f
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"><div=
>I agree with Gavin - whilst it&#39;s great that a Blockstream employee has=
 finally made a realistic proposal (i.e. not &quot;let&#39;s all use Lightn=
ing&quot;) - this BIP is virtually the same as keeping the 1mb cap.</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><p dir=3D"ltr">Well, centralization of mining =
is already terrible. I see no reason why we should encourage making it wors=
e.</p></blockquote><div>Centralization of mining has been a continual gripe=
 since Slush first invented pooled mining. There has never been a time afte=
r that when people weren&#39;t talking about the centralisation of mining, =
and back then blocks were ~10kb.=C2=A0</div><div><br></div><div>I see const=
ant assertions that node count, mining centralisation, developers not using=
 Bitcoin Core in their own businesses etc is all to do with block sizes. Bu=
t nobody has shown that. Nobody has even laid the groundwork for that. Veri=
fying blocks takes milliseconds and downloading them takes seconds everywhe=
re except, apparently, China: this resource usage is trivial.=C2=A0</div><d=
iv><br></div><div>Yet developers, miners and users even outside of China ro=
utinely delegate validation to others. Often for quite understandable techn=
ical reasons that have nothing to do with block sizes.</div><div><br></div>=
<div>So I see no reason why arbitrarily capping the block size will move th=
e needle on these metrics. Trying to arrest the growth of Bitcoin for every=
one won&#39;t suddenly make Bitcoin-Qt a competitive wallet, or make servic=
e devs migrate away from <a href=3D"http://chain.com">chain.com</a>, or mak=
e merchants stop using BitPay.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><p dir=3D"ltr">We need to accept that, and all previous proposals I&=
#39;ve seen don&#39;t seem to do that.</p></blockquote><div>I think that=
9;s a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth you&#39;re righ=
t, some use cases will be priced out. I initiated the micropayment channels=
 project (along with Matt, tip of the hat) specifically to optimise a certa=
in class of transactions. Even with 8mb+ blocks, there will still be a need=
 for micropayment channels, centralised exchange platforms and other forms =
of off chain transaction.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><p dir=3D"ltr">If Bitcoin needs to support a large scale, it already fail=
ed.<br></p></blockquote><div>It hasn&#39;t even been tried.=C2=A0</div><div=
><br></div><div><div>The desperately sad thing about all of this is that th=
ere&#39;s going to be a fork, and yet I think most of us agree on most thin=
gs.=C2=A0 But we don&#39;t agree on this.=C2=A0</div><div><br></div><div>Bi=
tcoin can support a large scale and it must, for all sorts of reasons. Amon=
gst others:</div><div><ol><li>Currencies have network effects. A currency t=
hat has few users is simply not competitive with currencies that have many.=
 There&#39;s no such thing as a settlement currency for high value transact=
ions only, as evidenced by the ever-dropping importance of gold.<br><br><br=
></li><li>A decentralised currency that the vast majority can&#39;t use doe=
sn&#39;t change the amount of centralisation in the world. Most people will=
 still end up using banks, with all the normal problems. You cannot solve a=
 problem by creating a theoretically pure solution that&#39;s out of reach =
of ordinary people: just ask academic cryptographers!<br><br><br></li><li>G=
rowth is a part of the social contract. It always has been.=C2=A0<br><br>Th=
e best quote Gregory can find to suggest Satoshi wanted small blocks is a o=
ne sentence hypothetical example about what <i>might</i> happen if Bitcoin =
users became &quot;tyrannical&quot; as a result of non-financial transactio=
ns being stuffed in the block chain. That position makes sense because his =
scaling arguments assuming payment-network-sized traffic and throwing DNS s=
ystems or whatever into the mix could invalidate those arguments, in the ab=
sence of merged mining. But Satoshi did invent merged mining, and so there&=
#39;s no need for Bitcoin users to get &quot;tyrannical&quot;: his original=
 arguments still hold.<br><br><br></li><li>All the plans for some kind of u=
ltra-throttled Bitcoin network used for infrequent transactions neglect to =
ask where the infrastructure for that will come from. The network of exchan=
ges, payment processors and startups that are paying people to build infras=
tructure are all=C2=A0based on the assumption that the market will grow sig=
nificantly. It&#39;s a gamble at best because Bitcoin&#39;s success is not =
guaranteed, but if the block chain cannot grow it&#39;s a gamble that is gu=
aranteed to be lost.<br><br>So why should anyone go through the massive has=
sle of setting up exchanges, without the lure of large future profits?<br><=
br><br></li><li>Bitcoin needs users, lots of them, for its political surviv=
al. There are many people out there who would like to see digital cash disa=
ppear, or be regulated out of existence. They will argue for that in front =
of governments and courts .... some already are. And if they&#39;re going t=
o lose those arguments, the political and economic damage of getting rid of=
 Bitcoin must be large enough to make people think twice. That means it nee=
ds supporters, it needs innovative services, it needs companies, and it nee=
ds legal users making legal payments: as many of them as possible.<br><br>I=
f Bitcoin is a tiny, obscure currency used by drug dealers and a handful of=
 crypto-at-any-cost geeks, the cost of simply banning it outright will seem=
 trivial and the hammer will drop. There won&#39;t be a large scale payment=
 network OR a high-value settlement network. And then the world is really s=
crewed, because nobody will get a second chance for a very long time.</li><=
/ol></div><div><br></div><div><br></div></div></div></div></div>

--001a113eceb2054cb8051c291e9f--