From: Peter Todd <pete@petertodd•org>
To: Ittay <ittay.eyal@cornell•edu>
Cc: "Bitcoin Dev" <bitcoin-development@lists•sourceforge.net>,
"Emin Gün Sirer" <egs@systems•cs.cornell.edu>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Date: Mon, 4 Nov 2013 11:07:16 -0500 [thread overview]
Message-ID: <20131104160716.GA3052@petertodd.org> (raw)
In-Reply-To: <CABT1wWmM466jWWdWAo5GmzP58xJFT70Vcr74ta+2QF2fWT+1SA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]
(not sure if you meant this to go to the list, my apologies if not)
On Mon, Nov 04, 2013 at 10:50:25AM -0500, Ittay wrote:
> On Mon, Nov 4, 2013 at 10:46 AM, Peter Todd <pete@petertodd•org> wrote:
>
> > On Mon, Nov 04, 2013 at 10:25:19AM -0500, Ittay wrote:
> > > Peter - how can you guarantee that the majority mines on the non-selfish
> > > block?
> >
> > Of course, it may be the case that competing near-block headers are
> > found, but no matter: as long as miners switch to the block with the
> > most hashing power, this forms a feedback effect that quickly brings
> > everyone to consensus. With everyone mining to extend the same block,
> > there's nothing the selfish miner can do; there's no disagreement to
> > exploit.
> >
>
> This is not the exploit! The majority you create might just as well follow
> the previously-private block, so we're back in square one.
Right, but the thing is, if all miners quickly come to consensus and are
all mining on the same block, there's nothing the attacker can exploit
in the first place.
Suppose Alice the attacker is 100 blocks ahead of the main network
somehow. We'll say the other miners are working to extend block n, and
she's in posession of 100 blocks extending that. She also has just under
50% of the hashing power.
Now when the main network finds a block n+1, Alice can do one of two
things: she can publish her own n+1 block, or she can do nothing. If she
does nothing, the main network will find block n+2 faster than she finds
n+101, so eventually she loses. Thus she has to publish.
In your attack she publishes to a subset of nodes strategicly, splitting
the hashing power between nodes working to extend her n+1, and the other
n+1 found. However, with near-target headers, very quickly all hashing
power will come to consensus and all work to extend the same block,
either theirs or Alice's. Given that they have the majority, they will
find another block faster on average than Alice can extend her lead, and
thus eventually Alice will lose.
Now there is still a slight advantage for Alice in that it takes some
time for the whole network to come to consensus, but this is a much
slimmer margin, maybe a few percentage points, so at best Alice might
need, say, 45% of the total hashing power.
--
'peter'[:-1]@petertodd.org
0000000000000004b8381fe97338c8b710cb662160f08e391820f30a375bb9b9
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-11-04 16:07 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 [this message]
[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=20131104160716.GA3052@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=egs@systems$(echo .)cs.cornell.edu \
--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