From: Matt Corallo <bitcoin-list@bluematt•me>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Date: Fri, 29 May 2015 23:25:27 +0000 [thread overview]
Message-ID: <5568F567.3050608@bluematt.me> (raw)
In-Reply-To: <CABsx9T2ysKj5HVbN_7_o33fMehs4KH6E_R583Mt_VPC4gDA0LQ@mail.gmail.com>
On 05/29/15 22:36, Gavin Andresen wrote:
> Matt brought this up on Twitter, I have no idea why I didn't respond
> weeks ago (busy writing blog posts, probably):
>
> On Thu, May 7, 2015 at 6:02 PM, Matt Corallo <bitcoin-list@bluematt•me
> <mailto:bitcoin-list@bluematt•me>> wrote:
>
>
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
>
>
> If block propagation isn't fixed, then mines have a strong incentive to
> create smaller blocks.
>
> So the max block size is irrelevant, it won't get hit.
Sadly, this is very far from the whole story. The issue of miners
optimizing for returns has been discussed several times during this
discussion, and, sadly, miners who are geographically colocated who are
optimizing for returns with a free-floating blocksize will optimize away
50% of the network!
>
> In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the
> system.
>
>
> See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for
> analysis of "but that means bigger miners can get an advantage" argument.
>
> Executive summary: if little miners are stupid and produce huge blocks,
> then yes, big miners have an advantage.
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, and miners dont even
have to be "evil" for this to happen - just optimize for profits.
> But they're not, so they won't.
I dont know what you're referring to with this. Are you claiming little
miners today optimize for relay times and have good visibility into the
Bitcoin network and calculate an optimal block size based on this (or
would with a 20MB block size)?
> Until the block reward goes away, and assuming transaction fees become
> an important source of revenue for miners.
> I think it is too early to worry about that; see:
>
> http://gavinandresen.ninja/when-the-block-reward-goes-away
You dont make any points here with which I can argue, but let me respond
with the reason /I/ think it is a problem worth thinking a little bit
about...If we increase the blocksize sufficiently such that transaction
fees are not the way in which miners make their money, then either
miners are not being funded (ie hashpower has to drop to very little),
or the only people mining/funding miners are large orgs who are
"running" Bitcoin (ie the web wallets, payment processors, big
merchants, and exchanges of the world). Sadly, this is no longer a
decentralized Bitcoin and is, in fact, pretty much how the banking world
works today.
I'm not sure who, if anyone, claims Bitcoin is novel or interesting for
any reason other than its decentralization properties, and, in a world
which you are apparently proposing, the "natural" course of things is to
very strongly centralize.
> * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace.
>
>
> Ok. What does this have to do with the max block size?
>
> Are you arguing that work won't happen if the max block size increases?
Yes, I am arguing that by increasing the blocksize the incentives to
actually make Bitcoin scale go away. Even if amazing technologies get
built, no one will have any reason to use them.
> * I'd like to see some better conclusions to the discussion around
>
> long-term incentives within the system.
>
>
> Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away
> for what I think about that.
next prev parent reply other threads:[~2015-05-29 23:25 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 [this message]
[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
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=5568F567.3050608@bluematt.me \
--to=bitcoin-list@bluematt$(echo .)me \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/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