[Bitcoin-development] Block Size Increase Requirements

Gavin Andresen gavinandresen at gmail.com
Fri May 29 22:36:51 UTC 2015


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 at 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.


> 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.

But they're not, so they won't.

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


>  * 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?

  * 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.

-- 
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/c145f6b9/attachment.html>


More information about the bitcoin-dev mailing list