From: Gavin Andresen <gavinandresen@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Tue, 23 Jun 2015 17:24:23 -0400 [thread overview]
Message-ID: <CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com> (raw)
In-Reply-To: <20150623204646.GA18677@muck>
[-- Attachment #1: Type: text/plain, Size: 2622 bytes --]
On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@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
[-- Attachment #2: Type: text/html, Size: 3737 bytes --]
next prev parent reply other threads:[~2015-06-23 21:24 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 18:18 Gavin Andresen
2015-06-22 18:33 ` Tier Nolan
2015-06-22 18:46 ` Gavin Andresen
2015-06-22 19:10 ` Martin Schwarz
2015-06-22 19:28 ` Tier Nolan
2015-06-22 19:54 ` Gavin Andresen
2015-06-22 20:12 ` Peter Todd
2015-06-22 19:23 ` Peter Todd
2015-06-23 7:35 ` Ross Nicoll
2015-08-17 15:58 ` Jorge Timón
2015-06-23 19:16 ` Peter Todd
2015-06-22 20:27 ` Kalle Rosenbaum
2015-06-22 20:46 ` Gavin Andresen
2015-06-22 20:51 ` Gavin Andresen
2015-06-22 21:52 ` Mark Friedenbach
2015-06-23 19:28 ` Peter Todd
2015-06-23 20:12 ` Gavin Andresen
2015-06-23 20:26 ` Pieter Wuille
2015-06-23 20:50 ` Peter Todd
2015-06-24 6:14 ` grarpamp
2015-06-23 20:46 ` Peter Todd
2015-06-23 21:24 ` Gavin Andresen [this message]
2015-06-26 19:08 ` Peter Todd
2015-06-26 22:01 ` Ivan Brightly
2015-06-26 19:25 ` Peter Todd
2015-06-26 22:16 ` Simon Liu
2015-06-27 2:14 ` Milly Bitcoin
2015-06-23 20:55 ` Roy Badami
2015-06-24 1:43 ` odinn
2015-06-24 3:05 ` William Madden
2015-06-24 3:49 ` Jeff Garzik
2015-06-24 13:06 ` Will
2015-06-24 13:44 ` Gavin Andresen
2015-06-25 0:32 ` Pindar Wong
2015-06-25 13:50 ` Gareth Williams
2015-06-25 14:07 ` Adam Back
2015-06-26 13:47 ` Tier Nolan
2015-06-26 15:13 ` Will
2015-06-26 17:39 ` Gavin Andresen
2015-06-26 19:07 ` Will
2015-07-01 22:49 ` odinn
2015-08-17 13:15 ` Tier Nolan
2015-08-17 13:18 ` Clément Elbaz
2015-08-19 3:45 ` odinn
2015-08-17 16:11 ` Jorge Timón
2015-06-26 21:07 ` Carsten Otto
2015-06-22 19:32 Jean-Paul Kogelman
2015-06-22 20:43 ` Tier Nolan
2015-06-22 20:54 ` Peter Todd
2015-06-22 21:04 ` Stephen Morse
2015-06-22 21:32 ` Ross Nicoll
2015-08-17 15:54 ` Jorge Timón
2015-06-22 21:21 ` Gavin Andresen
2015-06-22 21:39 ` Patrick Strateman
2015-06-22 21:48 ` Tier Nolan
2015-06-23 7:59 Ross Nicoll
2015-06-24 4:31 Raystonn
2015-06-24 17:05 ` Mark Friedenbach
2015-06-24 17:24 ` Roy Badami
2015-06-24 17:23 Raystonn
2015-06-24 17:24 ` Allen Piscitello
2015-06-24 17:28 ` Roy Badami
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='CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/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