From: Peter Todd <pete@petertodd•org>
To: Alan Reiner <etotheipi@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Date: Mon, 4 Nov 2013 17:03:17 -0500 [thread overview]
Message-ID: <20131104220317.GC4443@petertodd.org> (raw)
In-Reply-To: <52781574.1000904@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]
On Mon, Nov 04, 2013 at 04:45:24PM -0500, Alan Reiner wrote:
> So given the assumption that Alice is "well-connected" as Peter
> mentioned, it seems like this is a concern. But is this a realistic
> assumption? All miners have an incentive to be thoroughly connected to
> one another, to make sure they minimize the amount of time they spend
> mining on forks and that their blocks win with minimal chance of being
> orphaned. Is it realistic that one miner can somehow monopolize the
> good connections when the big miners are already trying to do the same
> thing for honest reasons? If you have a network full of honest miners
> and this one selfish-miner, it seems that all the honest miners need to
> do is try to establish those connections to each other as well as Alice
> does, and Alice will end up orphaning all her profit away.
Right, but as I said, I think this is likely to become a contest of who
can create the lowest latency mining operation, or to be more precise,
who can get the best ratio of latency per dollar.
Unfortunately even with totally "honest" mining winning orphan rates is
a function of latency; what this paper has done is mainly show a
remarkably effective way of leveraging low-latency and very good
visibility to the network.
Regardless, globe-spanning low-latency networks cost a lot of money, so
if they are something that makes mining more profitable, for whatever
reason, that's an effect that will incentivise pools to grow larger and
more centralized.
> Furthermore, you can de-incentivize it by simply randomizing the order
> of broadcasts. Although you are maintaining multiple concurrent
> connections, the data still exits your network card as a serial stream
> of packets, and it seems that if you randomize who gets your new-block
> broadcasts first, then it further reduces the Alice's advantage if she's
> not guaranteed to "be first." Sure, she can do it sometimes, but it
> would seem that even a couple failures to beat the rest of the network
> is going to erase most/all of what she gained on the blocks/chains that
> she wins.
Yeah, there's a lot of possible solutions, but what I'm seeing looking
at them is they all tend to be not economically rational, in the short
term, or even worse, they actually incentivize mining pools to get
larger. For instance anything that tries to prevent Alice from sybiling
the network by forcing nodes to prove they have mining capacity just
means that larger miners will have an advantage over smaller ones in
getting their blocks propagated as fast as possible. Once Alice does
have a reasonable amount of mining capacity, she can still use the
selfish miner attack to grow larger and more profitable.
--
'peter'[:-1]@petertodd.org
000000000000000aae6d13639c5b4555eeda301ebcbc53f12e8a633e267c8331
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-11-04 22:03 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 11:26 Mike Hearn
2013-11-04 11:53 ` Peter Todd
2013-11-04 12:00 ` Mike Hearn
2013-11-04 18:16 ` [Bitcoin-development] Committing to extra block data/a better merge-mine standard Peter Todd
2013-11-04 18:32 ` Peter Todd
2013-11-04 19:11 ` Mark Friedenbach
2013-11-15 22:06 ` Peter Todd
2013-11-04 19:38 ` Mike Hearn
2013-11-04 19:53 ` Mark Friedenbach
2013-11-04 20:10 ` Mike Hearn
2013-11-04 11:58 ` [Bitcoin-development] Auto-generated miner backbone Michael Gronager
2013-11-04 12:03 ` Mike Hearn
2013-11-04 12:20 ` Peter Todd
2013-11-04 12:40 ` Michael Gronager
2013-11-04 15:58 ` Gregory Maxwell
2013-11-04 14:26 ` Peter Todd
2013-11-04 14:34 ` Pieter Wuille
2013-11-04 14:46 ` Peter Todd
[not found] ` <CABT1wWm1NzKSS9H=Qh3Z6pFmNHbOFKC12WaE=b3kE0mNsRgfmw@mail.gmail.com>
2013-11-04 15:04 ` Peter Todd
[not found] ` <CABT1wWmONUeOWRg-=FKr88bgBQf0un4bvjYW2h8d-10ys-VKtA@mail.gmail.com>
2013-11-04 15:46 ` Peter Todd
[not found] ` <CABT1wWmM466jWWdWAo5GmzP58xJFT70Vcr74ta+2QF2fWT+1SA@mail.gmail.com>
2013-11-04 16:07 ` Peter Todd
[not found] ` <CABT1wWm5BDZf7U40pOqZvTqdOKeTWUTekjUNckq5McMV=LDu_g@mail.gmail.com>
2013-11-04 16:51 ` Peter Todd
[not found] ` <CABT1wWmwb17b4ACHMmDKqd94tUSKsvwAPx344mZ0VS+47myeWg@mail.gmail.com>
2013-11-04 21:04 ` Peter Todd
2013-11-04 21:45 ` Alan Reiner
2013-11-04 22:03 ` Peter Todd [this message]
2013-11-04 15:27 ` Mike Hearn
2013-11-04 17:36 ` Peter Todd
2013-11-04 15:51 ` Gregory Maxwell
2013-11-05 4:14 Gustaw Wieczorek
2013-11-05 4:39 ` Peter Todd
2013-11-05 6:37 ` Gregory Maxwell
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=20131104220317.GC4443@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@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