From: "Jeremy Spilman" <jeremy@taplink•co>
To: "Peter Todd" <pete@petertodd•org>, Ittay <ittay.eyal@cornell•edu>
Cc: "Bitcoin Dev" <bitcoin-development@lists•sourceforge.net>,
"Gavin Andresen" <gavin@bitcoinfoundation•org>,
"Emin Gün Sirer" <egs@systems•cs.cornell.edu>
Subject: Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
Date: Tue, 05 Nov 2013 10:57:34 -0800 [thread overview]
Message-ID: <op.w53ax8dtyldrnw@laptop-air> (raw)
In-Reply-To: <CABT1wWnPJOKKT5v2hGePkUT8jNau=TEK5s-n2so2kQKnv-HfqQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]
Great paper Ittay, thanks for all your work on this.
> Today the threshold is 0% with good connectivity.
Fig. 2 captures this well, the threshold is only zero if 'y' is 1. In
Section 6 and 6.1 you argue y -> 1 but the sybil attack you describe,
isn't that more like how *all* sophisticated miners would want to ensure
their blocks are widely propagated? I think you can't assume only the
selfish miner is doing it.
Based on the current 'first seen' algorithm, as you say, competing
longest chains happen about every 60 blocks. The rest of the time, a
single block propagates through the vast majority of the network
'uncontested'. If there are multiple valid longest blocks being
simultaneously propagated, then propagation pattern of the competing
blocks will determine hash rate on each.
Selfish mining requires exploiting the race condition between learning
about a competing block, and publishing your own. Usually we talk about
minimizing publishing latency so that your block ends up uncontested 59/60
times, and in the 1/60 times, even then your block has the best chance of
winning.
Selfish mining forgoes the 59/60 chance of your block being uncontested,
and instead chooses to 'race the network' every time. You start 'one step
behind' the competing block (since of course you only learn about it after
it starts propagating), so you must rely on being able to outrace
propagation of the competing block through a private low-latency
side-network which can inject your block at multiple points throughout the
bitcoin p2p network to outrace the competitor.
I think it's a stretch to say 'y' is 0 with good connectivity. Even the
best connected mining pools today are concerned with this 'y' factor.
Here's a probably very dumb idea... to throw out one possible "solution"...
You want a way to fake-out the 'selfish miner' into disclosing their
blocks -- how can your force their hand to prevent them from accumulating
longer private chains?
What if you propagate (and relay) an encrypted block header which honest
miners will timestamp when they receive it, then 10 seconds later
propagate the decryption key to unblind it. But here's the catch - maybe
the decryption results in junk, maybe it results a new longer block. If
it's a real block then it gets priority based on when the ciphertext was
received instead of when the decryption key was received. Now 'selfish
miner' can't race the network anymore, because they are always in state 0'
and can't tell if they are up against a ghost, or a real competing block.
If they wait for the decryption key to check, it's too late, and they are
guaranteed to lose unless they can out-race the network, e.g. back at
t=50%. Of course there would need to be some way to anti-DDoS this which
allows for some amount of these fake-outs without letting them get out of
hand.
Thanks,
Jeremy
[-- Attachment #2.1: Type: text/html, Size: 3441 bytes --]
next prev parent reply other threads:[~2013-11-05 18:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 16:56 Ittay
2013-11-05 17:05 ` Peter Todd
2013-11-05 17:14 ` Peter Todd
2013-11-05 17:43 ` Ittay
2013-11-05 17:54 ` Mike Hearn
2013-11-05 18:07 ` Alessandro Parisi
2013-11-05 18:37 ` Jeff Garzik
2013-11-05 18:55 ` Alessandro Parisi
2013-11-05 18:58 ` Jeff Garzik
2013-11-05 19:33 ` Jameson Lopp
2013-11-05 19:56 ` Peter Todd
2013-11-05 17:26 ` Ittay
2013-11-05 17:37 ` Patrick
2013-11-05 18:18 ` Alessandro Parisi
2013-11-05 18:57 ` Jeremy Spilman [this message]
2013-11-05 22:49 ` Ittay
2013-11-07 20:05 ` [Bitcoin-development] comments on selfish-mining model (Re: BIP proposal - patch to raise selfish mining threshold.) Adam Back
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=op.w53ax8dtyldrnw@laptop-air \
--to=jeremy@taplink$(echo .)co \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=egs@systems$(echo .)cs.cornell.edu \
--cc=gavin@bitcoinfoundation$(echo .)org \
--cc=ittay.eyal@cornell$(echo .)edu \
--cc=pete@petertodd$(echo .)org \
/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