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: Fri, 26 Jun 2015 15:08:07 -0400 [thread overview]
Message-ID: <20150626190739.GB10387@muck> (raw)
In-Reply-To: <CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]
On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
> 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).
"Just rent a server" forces miners into deploying insecure hosted
infrastructure that's vulnerable to hacking and seizure; that we
encourage this already is worrying; requiring it for miners to be
profitable isn't acceptable.
> 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.
See above. The obvious thing to do if connectivity matters is keep your
hashing in the cheapest possible place and sell that hashing power to
centralized miners, an effect we're already seeing. Making this effect
about an order of magnitude worse, then doubling the problem every two
years is dangerous.
> 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.
As mining and hashing can be trivially separated that theory just
doesn't work.
Again, what concretely works against centralization of mining control?
A proper proposal would discuss this issue, and explain what the
expected effect will be.
> > 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.
The co-operation comes form the fact that mempool policies have to be
syncronized, not the protocol itself.
--
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-06-26 19:08 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
2015-06-26 19:08 ` Peter Todd [this message]
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=20150626190739.GB10387@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