From: Peter Todd <pete@petertodd•org>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Tue, 23 Jun 2015 16:46:47 -0400 [thread overview]
Message-ID: <20150623204646.GA18677@muck> (raw)
In-Reply-To: <CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]
On Tue, Jun 23, 2015 at 04:12:17PM -0400, Gavin Andresen wrote:
> > In particular, if bandwidth scaling doesn't go according to your plan,
> > e.g. the exponential exponent is too large, perhaps due to technological
> > growth not keeping pace, or the political realities of actual bandwidth
> > deployment making theoretical technological growth irrelevant, what
> > mechanism will prevent centralization? (if any)
>
>
> Simulations show that:
>
> Latency/bandwidth matter for miners. Low latency, high bandwidth is
> better. However, miners with bad connectivity can simply create smaller
> blocks...
Pieter Wuille showed with simulations that miners with bad connectivity
are negatively affected by other miners creating larger blocks.
Similarly I showed that with equation-based analysis. I've seen no
response to either argument, and it's a centralization pressure.
Note how propagation times are important enough to miners that they
already mine on top of unverified headers from other miners to increase
profitability, a grave threat to the security of the Bitcoin network.
> ... 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.
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 scenarios.
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.
--
'peter'[:-1]@petertodd.org
000000000000000008c0be16e152f86ab3a271a13c3f41c56228d72990abf7bd
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-06-23 20:46 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 [this message]
2015-06-23 21:24 ` Gavin Andresen
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=20150623204646.GA18677@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--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