path: root/1f/47c1d290db292fdb85faf8264d03042d18dc25

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1YynVU-0004VH-EU
	for bitcoin-development@lists.sourceforge.net;
	Sat, 30 May 2015 20:37:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.47 as permitted sender)
	client-ip=209.85.215.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f47.google.com; 
Received: from mail-la0-f47.google.com ([209.85.215.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YynVS-00033l-DP
	for bitcoin-development@lists.sourceforge.net;
	Sat, 30 May 2015 20:37:24 +0000
Received: by laat2 with SMTP id t2so77003913laa.1
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 30 May 2015 13:37:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.72.164 with SMTP id e4mr10617750lbv.113.1433018235914;
	Sat, 30 May 2015 13:37:15 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Sat, 30 May 2015 13:37:15 -0700 (PDT)
In-Reply-To: <556A1046.50807@bluematt.me>
References: <554BE0E1.5030001@bluematt.me>
	<CABsx9T2ysKj5HVbN_7_o33fMehs4KH6E_R583Mt_VPC4gDA0LQ@mail.gmail.com>
	<5568F567.3050608@bluematt.me>
	<CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
	<556A1046.50807@bluematt.me>
Date: Sat, 30 May 2015 16:37:15 -0400
Message-ID: <CABsx9T3qPiQ+PL3ZNT+QJzw4ALEzKjMjC4=uEKTG+4vVPdXr-g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=001a11c2b616e8919a0517528e30
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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
X-Headers-End: 1YynVS-00033l-DP
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Sat, 30 May 2015 20:37:24 -0000

--001a11c2b616e8919a0517528e30
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, May 30, 2015 at 3:32 PM, Matt Corallo <bitcoin-list@bluematt.me>
wrote:

> If, for example, the majority of miners are in China (they are), and
> there is really poor connectivity in and out of China (there is) and a
> miner naively optimizes for profit, they will create blocks which are
> large and take a while to relay out of China. By simple trial-and-error
> an individual large miner might notice that when they create larger
> blocks which fork off miners in other parts of the world, they get more
> income. Obviously forking off 50% of the network would be a rather
> extreme situation and assumes all kinds of simplified models, but it
> shows that the incentives here are very far from aligned, and your
> simplified good-behavior models are very far from convincing.
>

"good behavior" models? I intentionally modeled what should be a worst-case=
.

If you have a specific network topology you want to model, please email me
details and I'll see what worst case is. Or, even better, take my
simulation code and run it yourself (it's C++, easy to compile, easy to
modify if you think it is too simple).

I get frustrated with all of the armchair "but what if..."
how-many-miners-can-dance-on-the-head-of-a-pin arguments.



> >     I'll talk about transaction fees in a second, but there are several
> >     problems with this already. As pointed out in the original mail, gf=
w
> has
> >     already been known to interfere with Bitcoin P2P traffic. So now by
> >     "little" miners, you mean any miner who is not located in mainland
> >     China? Whats worse, the disadvantage is symmetric - little miners
> are at
> >     a disadvantage when *anyone* mines a bigger block


No, they're not. They are only at a disadvantage when THEY mine bigger
blocks.

I guess I wasn't clear in the "do bigger miners have an advantage" blog
post.


> ... I mentioned this in my
> original email as something which doesnt make me comfortable with 20MB
> blocks, but something which needs simulation and study, and might
> actually be just fine!
>

I spent last week doing simulation and study. Please, do your own
simulation and study if you don't trust my results. There are big
full-scale-bitcoin-network-simulations spinning up that should have results
in a month or two, also, but there will ALWAYS be "but we didn't think
about what if THIS happens" scenarios that can require more simulation and
study.


>
> > Do you have another explanation for why miners choose to leave
> > fee-paying transactions in their mempool and create small blocks?
>
> Defaults? Dumb designs? Most miners just use the default 750K blocks, as
> far as I can tell, other miners probably didnt see transactions relayed
> across several hops or so, and a select few miners are doing crazy
> things like making their blocks fit in a single packet to cross the gfw,
> but that is probably overkill and not well-researched.
>

Last night's transaction volume test shows that most miners do just go
along with defaults:
  http://bitcoincore.org/~gavin/sizes_358594.html

> I'm not suggesting that we increase the blocksize sufficiently such that
> > transaction fees are not the way in which miners make their money.
> >
> > I'm suggesting the blocksize be increased to 20MB (and then doubled
> > every couple of years).
>
> Do you have convincing evidence that at 20MB miners will be able to
> break even on transaction fees for a long time? (The answer is no
> because no one has any idea how bitcoin transaction volumes are going to
> scale, period.)
>


Mining is a competitive business, the marginal miner will ALWAYS be going
out of business.

That is completely independent of the block size, block subsidy, or
transaction fees.

The question is "will there be enough fee+subsidy revenue to make it
unprofitable for an attacker to buy or rent enough hashpower to
double-spend."

It is obvious to me that bigger blocks make it more likely the answer to
that question is "yes."



>
> > And "in which miners make their money" is the wrong metric-- we want
> > enough mining so the network to be "secure enough" against double-spend=
s.
>
> Sure, do you have a value of hashpower which is "secure enough" (which
> is a whole other rabbit hole to go down...).
>

Mike Hearn wrote about that just a couple days ago:
  https://medium.com/@octskyward/hashing-7d04a887acc8
(See "How much is too much" section)


> > Even if we end up in a world where only big companies can run full node=
s
> > (and I am NOT NOT NOT NOT NOT proposing any such thing), there is a
> > difference-- you don't need permission to "open up a bank" on the
> > Bitcoin network.
> >
>
> Oh? You mention at http://gavinandresen.ninja/bigger-blocks-another-way
> that "I struggle with wanting to stay true to Satoshi=E2=80=99s original =
vision
> of Bitcoin as a system that scales up to Visa-level transaction volume".
> That is in direct contradiction.
>

I have said repeatedly that if it was left completely up to me I would go
back to Satoshi's original "there is no consensus-level blocksize limit".

20MB is a compromise.

 > Ok, I wrote about that here:

> >
> > http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
> >
>
> "it is not a panacea", but everyone in the community seems to be taking
> it as one. You've claimed many times that many of the big
> webwallet/payment processors/etc have been coming to you and saying they
> need bigger block sizes to continue operating. In reality, they dont, it
> just makes it easier
>
>
... and now you're pissing me off. I have NEVER EVER said that they need
bigger blocks to continue operating. Please stop being overly dramatic.

They believe that bigger blocks are better for Bitcoin.

Brian Armstrong at Coinbase, in particular, said that smaller blocks drive
centralization towards services like Coinbase ("look ma! No blockchain
transaction!" <-- if you pay a Coinbase merchant from your Coinbase
wallet), but he supports bigger blocks because more transactions on our
existing decentralized network is better.

--=20
--
Gavin Andresen

--001a11c2b616e8919a0517528e30
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">On S=
at, May 30, 2015 at 3:32 PM, Matt Corallo <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bitcoin-list@bluematt.me" target=3D"_blank">bitcoin-list@bluematt.me=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">If, for example, the majority of=
 miners are in China (they are), and<br>
there is really poor connectivity in and out of China (there is) and a<br>
miner naively optimizes for profit, they will create blocks which are<br>
large and take a while to relay out of China. By simple trial-and-error<br>
an individual large miner might notice that when they create larger<br>
blocks which fork off miners in other parts of the world, they get more<br>
income. Obviously forking off 50% of the network would be a rather<br>
extreme situation and assumes all kinds of simplified models, but it<br>
shows that the incentives here are very far from aligned, and your<br>
simplified good-behavior models are very far from convincing.<br></blockquo=
te><div><br></div><div>&quot;good behavior&quot; models? I intentionally mo=
deled what should be a worst-case.</div><div><br></div><div>If you have a s=
pecific network topology you want to model, please email me details and I&#=
39;ll see what worst case is. Or, even better, take my simulation code and =
run it yourself (it&#39;s C++, easy to compile, easy to modify if you think=
 it is too simple).</div><div><br></div><div>I get frustrated with all of t=
he armchair &quot;but what if...&quot; how-many-miners-can-dance-on-the-hea=
d-of-a-pin arguments.</div><div><br></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><span class=3D"">
&gt;=C2=A0 =C2=A0 =C2=A0I&#39;ll talk about transaction fees in a second, b=
ut there are several<br>
&gt;=C2=A0 =C2=A0 =C2=A0problems with this already. As pointed out in the o=
riginal mail, gfw has<br>
&gt;=C2=A0 =C2=A0 =C2=A0already been known to interfere with Bitcoin P2P tr=
affic. So now by<br>
&gt;=C2=A0 =C2=A0 =C2=A0&quot;little&quot; miners, you mean any miner who i=
s not located in mainland<br>
&gt;=C2=A0 =C2=A0 =C2=A0China? Whats worse, the disadvantage is symmetric -=
 little miners are at<br>
&gt;=C2=A0 =C2=A0 =C2=A0a disadvantage when *anyone* mines a bigger block</=
span></blockquote><div><br></div><div>No, they&#39;re not. They are only at=
 a disadvantage when THEY mine bigger blocks.</div><div><br></div><div>I gu=
ess I wasn&#39;t clear in the &quot;do bigger miners have an advantage&quot=
; blog post.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">...</=
span>=C2=A0I mentioned this in my<br>
original email as something which doesnt make me comfortable with 20MB<br>
blocks, but something which needs simulation and study, and might<br>
actually be just fine!<span class=3D""><br></span></blockquote><div><br></d=
iv><div>I spent last week doing simulation and study. Please, do your own s=
imulation and study if you don&#39;t trust my results. There are big full-s=
cale-bitcoin-network-simulations spinning up that should have results in a =
month or two, also, but there will ALWAYS be &quot;but we didn&#39;t think =
about what if THIS happens&quot; scenarios that can require more simulation=
 and study.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D""><br>
&gt; Do you have another explanation for why miners choose to leave<br>
&gt; fee-paying transactions in their mempool and create small blocks?<br>
<br>
</span>Defaults? Dumb designs? Most miners just use the default 750K blocks=
, as<br>
far as I can tell, other miners probably didnt see transactions relayed<br>
across several hops or so, and a select few miners are doing crazy<br>
things like making their blocks fit in a single packet to cross the gfw,<br=
>
but that is probably overkill and not well-researched.<br></blockquote><div=
><br></div><div>Last night&#39;s transaction volume test shows that most mi=
ners do just go along with defaults:</div><div>=C2=A0=C2=A0<a href=3D"http:=
//bitcoincore.org/~gavin/sizes_358594.html">http://bitcoincore.org/~gavin/s=
izes_358594.html</a></div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">=
&gt; I&#39;m not suggesting that we increase the blocksize sufficiently suc=
h that<br>
&gt; transaction fees are not the way in which miners make their money.<br>
&gt;<br>
&gt; I&#39;m suggesting the blocksize be increased to 20MB (and then double=
d<br>
&gt; every couple of years).<br>
<br>
</span>Do you have convincing evidence that at 20MB miners will be able to<=
br>
break even on transaction fees for a long time? (The answer is no<br>
because no one has any idea how bitcoin transaction volumes are going to<br=
>
scale, period.)<br></blockquote><div><br></div><div><br></div><div>Mining i=
s a competitive business, the marginal miner will ALWAYS be going out of bu=
siness.<br></div><div><br></div><div>That is completely independent of the =
block size, block subsidy, or transaction fees.</div><div><br></div><div>Th=
e question is &quot;will there be enough fee+subsidy revenue to make it unp=
rofitable for an attacker to buy or rent enough hashpower to double-spend.&=
quot;</div><div><br></div><div>It is obvious to me that bigger blocks make =
it more likely the answer to that question is &quot;yes.&quot;</div><div><b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">
<span class=3D""><br>
&gt; And &quot;in which miners make their money&quot; is the wrong metric--=
 we want<br>
&gt; enough mining so the network to be &quot;secure enough&quot; against d=
ouble-spends.<br>
<br>
</span>Sure, do you have a value of hashpower which is &quot;secure enough&=
quot; (which<br>
is a whole other rabbit hole to go down...).<br></blockquote><div><br></div=
><div>Mike Hearn wrote about that just a couple days ago:</div><div>=C2=A0=
=C2=A0<a href=3D"https://medium.com/@octskyward/hashing-7d04a887acc8">https=
://medium.com/@octskyward/hashing-7d04a887acc8</a></div><div>(See &quot;How=
 much is too much&quot; section)</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><sp=
an class=3D"">&gt; Even if we end up in a world where only big companies ca=
n run full nodes<br>
&gt; (and I am NOT NOT NOT NOT NOT proposing any such thing), there is a<br=
>
&gt; difference-- you don&#39;t need permission to &quot;open up a bank&quo=
t; on the<br>
&gt; Bitcoin network.<br>
&gt;<br>
<br>
</span>Oh? You mention at <a href=3D"http://gavinandresen.ninja/bigger-bloc=
ks-another-way" target=3D"_blank">http://gavinandresen.ninja/bigger-blocks-=
another-way</a><br>
that &quot;I struggle with wanting to stay true to Satoshi=E2=80=99s origin=
al vision<br>
of Bitcoin as a system that scales up to Visa-level transaction volume&quot=
;.<br>
That is in direct contradiction.<br></blockquote><div><br></div><div>I have=
 said repeatedly that if it was left completely up to me I would go back to=
 Satoshi&#39;s original &quot;there is no consensus-level blocksize limit&q=
uot;.</div><div><br></div><div>20MB is a compromise.</div><div><br></div><d=
iv>=C2=A0&gt; Ok, I wrote about that here:</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span clas=
s=3D"">
&gt;<br>
&gt; <a href=3D"http://gavinandresen.ninja/it-must-be-done-but-is-not-a-pan=
acea" target=3D"_blank">http://gavinandresen.ninja/it-must-be-done-but-is-n=
ot-a-panacea</a><br>
&gt;<br>
<br>
</span>&quot;it is not a panacea&quot;, but everyone in the community seems=
 to be taking<br>
it as one. You&#39;ve claimed many times that many of the big<br>
webwallet/payment processors/etc have been coming to you and saying they<br=
>
need bigger block sizes to continue operating. In reality, they dont, it<br=
>
just makes it easier<br><br></blockquote><div>=C2=A0</div></div>... and now=
 you&#39;re pissing me off. I have NEVER EVER said that they need bigger bl=
ocks to continue operating. Please stop being overly dramatic.</div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">They believe that =
bigger blocks are better for Bitcoin.</div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">Brian Armstrong at Coinbase, in particular,=
 said that smaller blocks drive centralization towards services like Coinba=
se (&quot;look ma! No blockchain transaction!&quot; &lt;-- if you pay a Coi=
nbase merchant from your Coinbase wallet), but he supports bigger blocks be=
cause more transactions on our existing decentralized network is better.<br=
 clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature">--<br>G=
avin Andresen<br></div>
</div></div>

--001a11c2b616e8919a0517528e30--