From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <5568F567.3050608@bluematt.me> <556A1046.50807@bluematt.me> Date: Sat, 30 May 2015 16:37:15 -0400 Message-ID: From: Gavin Andresen To: Matt Corallo 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
On S= at, 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 mo= deled what should be a worst-case.

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's C++, easy to compile, easy to modify if you think= it is too simple).

I get frustrated with all of t= he armchair "but what if..." how-many-miners-can-dance-on-the-hea= d-of-a-pin arguments.

=C2=A0
>=C2=A0 =C2=A0 =C2=A0I'll talk about transaction fees in a second, b= ut there are several
>=C2=A0 =C2=A0 =C2=A0problems with this already. As pointed out in the o= riginal mail, gfw has
>=C2=A0 =C2=A0 =C2=A0already been known to interfere with Bitcoin P2P tr= affic. So now by
>=C2=A0 =C2=A0 =C2=A0"little" miners, you mean any miner who i= s not located in mainland
>=C2=A0 =C2=A0 =C2=A0China? Whats worse, the disadvantage is symmetric -= little miners are at
>=C2=A0 =C2=A0 =C2=A0a disadvantage when *anyone* mines a bigger block

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

I gu= ess I wasn't clear in the "do bigger miners have an advantage"= ; blog post.
=C2=A0
...=C2=A0I 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 s= imulation and study if you don'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 "but we didn't think = about what if THIS happens" scenarios that can require more simulation= and study.
=C2=A0

> 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 mi= ners do just go along with defaults:

= > I'm not suggesting that we increase the blocksize sufficiently suc= h that
> transaction fees are not the way in which miners make their money.
>
> I'm suggesting the blocksize be increased to 20MB (and then double= d
> every couple of years).

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
because no one has any idea how bitcoin transaction volumes are going to scale, period.)


Mining i= s a competitive business, the marginal miner will ALWAYS be going out of bu= siness.

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

Th= e question is "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;

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

> And "in which miners make their money" is the wrong metric--= we want
> enough mining so the network to be "secure enough" against d= ouble-spends.

Sure, do you have a value of hashpower which is "secure enough&= quot; (which
is a whole other rabbit hole to go down...).

Mike Hearn wrote about that just a couple days ago:
(See "How= much is too much" section)
=C2=A0
> Even if we end up in a world where only big companies ca= n run full nodes
> (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&quo= t; 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 origin= al 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&q= uot;.

20MB is a compromise.

=C2=A0> Ok, I wrote about that here:
>
> http://gavinandresen.ninja/it-must-be-done-but-is-n= ot-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

=C2=A0
... and now= you're pissing me off. I have NEVER EVER said that they need bigger bl= ocks to continue operating. Please stop being overly dramatic.

They believe that = bigger blocks are better for Bitcoin.

<= /div>
Brian Armstrong at Coinbase, in particular,= said that smaller blocks drive centralization towards services like Coinba= se ("look ma! No blockchain transaction!" <-- 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.

--
--
G= avin Andresen
--001a11c2b616e8919a0517528e30--