From: Peter Todd <pete@petertodd•org>
To: Ittay <ittay.eyal@cornell•edu>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Date: Mon, 4 Nov 2013 10:04:06 -0500 [thread overview]
Message-ID: <20131104150406.GA2566@petertodd.org> (raw)
In-Reply-To: <CABT1wWm1NzKSS9H=Qh3Z6pFmNHbOFKC12WaE=b3kE0mNsRgfmw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
On Mon, Nov 04, 2013 at 09:49:09AM -0500, Ittay wrote:
> 1. Something important that is being overlooked is that the attack is
> relevant even without the sybil attack. Even if you assume the selfish
> miners loose every time on a 1:1 competition, they can still benefit in
> pools larger than 33%. And pools often reach this size.
>
> 2. The selfish pool can essentially hide its behavior behind multiple IP
> addresses. I fear employing an anti-sybil mechanism of this sort may expose
> new vulnerabilities. The current approach is great - the attacker cannot
> partition the network, only gain a slight timing advantage. Our approach
> just takes away the network-induced arbitrariness and replaces it with
> explicit randomness, which cannot introduce new vulnerabilities. It
> protects us from 25% attacks, which is excellent (though unfortunately not
> as good as the 51% security we believed before).
The problem is picking which side of the fork you mine on randomly isn't
rational for an individual miner. The time that you heard about a block
is important information: the block you heard about first is more likely
to have propagated to the majority of the hashing power than the one you
learn about second. You're rational incentive is to always mine on the
majority side as that side has the highest probability of no competing
blocks being found when the next block is found. (with the one exception
of the previous block being yours) In addition the next block found will
propagate to the majority of hashing power faster, as that majority
already has the previous block. By suggesting that miners pick randomly
half the time they will be going against their best interests. (if not
the interests of the network as a whole)
On the other hand my near-target broadcast solution gives miners honest
proof of what the majority actually is. Making use of that information
is the economically rational choice even at an individual level. Yet it
still defeats the attack, and it does better in returning the threshold
to the originally assumed 51% level.
--
'peter'[:-1]@petertodd.org
0000000000000005fa5454135b2638d1b2240d565737a24586f31490025e2de0
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-11-04 15:04 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 [this message]
[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
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=20131104150406.GA2566@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=ittay.eyal@cornell$(echo .)edu \
/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