From: Gavin Andresen <gavinandresen@gmail•com>
To: Matt Corallo <bitcoin-list@bluematt•me>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Date: Sat, 30 May 2015 16:37:15 -0400 [thread overview]
Message-ID: <CABsx9T3qPiQ+PL3ZNT+QJzw4ALEzKjMjC4=uEKTG+4vVPdXr-g@mail.gmail.com> (raw)
In-Reply-To: <556A1046.50807@bluematt.me>
[-- Attachment #1: Type: text/plain, Size: 6206 bytes --]
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, gfw
> 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-spends.
>
> 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 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" 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’s 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.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 9320 bytes --]
next prev parent reply other threads:[~2015-05-30 20:37 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 22:02 Matt Corallo
2015-05-07 23:24 ` Joseph Poon
2015-05-08 0:05 ` Peter Todd
2015-05-08 6:33 ` Arkady
2015-05-08 10:03 ` Mike Hearn
2015-05-08 16:37 ` Peter Todd
2015-05-08 19:47 ` Tier Nolan
2015-05-09 3:08 ` Peter Todd
2015-05-16 4:39 ` Stephen
2015-05-16 11:29 ` Tier Nolan
2015-05-16 11:25 ` Tier Nolan
2015-05-29 22:36 ` Gavin Andresen
2015-05-29 23:25 ` Matt Corallo
[not found] ` <CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
2015-05-30 19:32 ` Matt Corallo
2015-05-30 20:37 ` Gavin Andresen [this message]
2015-05-31 14:46 ` Jorge Timón
2015-05-31 14:49 ` Gavin Andresen
2015-05-31 14:59 ` Jorge Timón
2015-05-31 15:08 ` Gavin Andresen
2015-05-31 15:45 ` Jorge Timón
2015-05-29 23:42 ` Chun Wang
2015-05-30 13:57 ` Gavin Andresen
2015-05-30 14:08 ` Pindar Wong
2015-05-30 22:05 ` Alex Mizrahi
2015-05-30 23:16 ` Brian Hoffman
2015-05-31 0:13 ` Alex Mizrahi
2015-05-31 5:05 ` gb
[not found] ` <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
2015-05-31 1:31 ` [Bitcoin-development] Fwd: " Chun Wang
2015-05-31 2:20 ` Pindar Wong
2015-05-31 12:40 ` Gavin Andresen
2015-05-31 13:45 ` Alex Mizrahi
2015-05-31 14:54 ` Gavin Andresen
2015-05-31 22:55 ` Alex Mizrahi
2015-05-31 23:23 ` Ricardo Filipe
2015-05-31 23:40 ` Pindar Wong
2015-05-31 23:58 ` Ricardo Filipe
2015-06-01 0:03 ` Pindar Wong
2015-06-01 7:57 ` Alex Mizrahi
2015-06-01 10:13 ` Mike Hearn
2015-06-01 10:42 ` Pindar Wong
2015-06-01 11:26 ` Peter Todd
2015-06-01 12:19 ` Pindar Wong
2015-06-01 11:02 ` Chun Wang
2015-06-01 11:09 ` Pindar Wong
2015-06-01 11:20 ` Chun Wang
2015-06-01 13:59 ` Gavin Andresen
2015-06-01 14:08 ` Chun Wang
2015-06-01 15:33 ` Mike Hearn
2015-06-01 16:06 ` Ángel José Riesgo
2015-06-01 14:46 ` Oliver Egginger
2015-06-01 14:48 ` Chun Wang
2015-06-01 16:43 ` Yifu Guo
2015-06-01 20:01 ` Roy Badami
2015-06-01 20:15 ` Roy Badami
2015-06-01 13:21 ` Mike Hearn
2015-06-01 12:29 ` Warren Togami Jr.
2015-06-01 13:15 ` Gavin Andresen
2015-05-31 12:52 ` Gavin Andresen
2015-05-31 13:31 ` [Bitcoin-development] [Bulk] " gb
2015-05-31 19:49 ` Gavin Andresen
2015-05-31 14:17 ` [Bitcoin-development] " Dave Hudson
2015-05-31 14:34 ` Yifu Guo
2015-05-31 14:47 ` Gavin Andresen
2015-05-31 7:05 ` [Bitcoin-development] " Peter Todd
2015-05-31 12:51 ` Gavin Andresen
2015-05-30 23:18 Raystonn
2015-05-31 0:32 ` Alex Mizrahi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABsx9T3qPiQ+PL3ZNT+QJzw4ALEzKjMjC4=uEKTG+4vVPdXr-g@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoin-list@bluematt$(echo .)me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox