[bitcoin-dev] Draft BIP : fixed-schedule block size increase

Gavin Andresen gavinandresen at gmail.com
Tue Jun 23 21:24:23 UTC 2015

On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete at petertodd.org> wrote:

> Pieter Wuille showed with simulations that miners with bad connectivity
> are negatively affected by other miners creating larger blocks.

... but the effect is only significant if they have an absurdly
low-bandwidth connection and do NOTHING to work around it (like rent a
server on the other side of the bandwidth bottleneck and write some code to
make sure you're creating blocks that will propagate quickly on both sides
of the bottleneck).

Why do you think connectivity is a centralizing effect? It is just one
factor in the profitability-of-mining equation. A location with bad
connectivity (the US, maybe) but 10% cheaper electricity might be just as
good as one with great connectivity but more expensive electricity.

Having lots of variables in the profitability equation is a decentralizing
force, it means there is very likely to be several different places in the
world / on the net where mining is equally profitable.

> ... until transaction fees become significant.  But by the time that
> > happens, protocol optimizations of block propagation will make the block
> > size an insignificant term in the "how profitable is it to mine in THIS
> > particular place on the Internet / part of the world" equation.
> These block propagation improvements are both already implemented (Matt
> Corallo's relay network, p2pool) and require co-operation.

Long term the p2p protocol will evolve to incorporate those optimizations,
so will require no co-operation.

> For instance, notice the recent full-RBF debate where Coinbase said
> they'd consider getting contracts directly with miners to get
> transactions they desired mined even when they otherwise would not be
> due to double-spends. This is one of many scenarios where block
> propagation improvements fail. Thus for a safety engineering
> analysis we need to talk about worst-case scenarioss

> Equally, I don't see any analysis from anyone of that % of non-optimized
> transactions need to fail for what kind of centralizing pressure.
> In any case, this ponts to the need for your proposal to explictly talk
> about what kind of resources are needed by miners for what kind of
> profitability, including the case where other miners are sabotaging
> their profitability.

Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ?

I have written quite a lot about the kind of resources needed to run a full
node, and have asked you, specifically, several times "how much do you
think is too much" and received no answer.

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

More information about the bitcoin-dev mailing list