From: Ittay <ittay.eyal@cornell.edu>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Cc: "Gavin Andresen" <gavin@bitcoinfoundation.org>,
"Emin Gün Sirer" <egs@systems.cs.cornell.edu>
Subject: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
Date: Tue, 5 Nov 2013 11:56:53 -0500 [thread overview]
Message-ID: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2515 bytes --]
Hello,
Please see below our BIP for raising the selfish mining threshold.
Looking forward to your comments.
Best,
Ittay
---
Bitcoin Improvement Proposal
Owners: Ittay Eyal and Emin Gun Sirer
We suggest a change in the propagation and mining algorithm for chains of
the same difficulty, to raise the threshold on Selfish Mining attacks.
* Current situation:
When a miner is notified of a new chain of the same difficulty as the one
it is mining on, it will ignore it.
* Background:
The selfish mining attack and its implications were described in detail in
the following research paper:
http://arxiv.org/abs/1311.0243v1
* Proposal:
To thwart selfish mining attacks launched by less than 25% of the mining
power, we propose the following change to the protocol:
When a miner learns of more than one chain of the same difficulty, it
should propagate all of them, and choose one of them to mine on uniformly
at random among all chains of the same difficulty.
When hearing of a chain of maximal difficulty that it did not know of
before:
1. Add it to a local list of maximal difficulty chains.
2. Propagate it to its neighbors.
3. Choose a branch uniformly at random from the local list, and mine on it.
* Example:
t0: learn of chain A of difficulty x.
propagate A to neighbors.
start mining on A.
t1: learn of chain B of difficulty x.
propagate B to neighbors.
toss a coin between A and B; if B wins, switch to mining on B.
t2: learn of chain C of difficulty x.
propagate C to neighbors.
toss a 3 faced coin among A, B, and C; switch to mining on the winning
chain.
* Concerns and answers:
1. No harm to miners when all are honest.
Mining blocks is a random Poisson process, which is memoryless. Having
mined on the block in the past does not provide an advantage in locating a
solution in the future. Therefore, a miner is not harmed by switching the
chain on which it mines.
2. No new vulnerabilities introduced:
Currently the choice among equal-length chains is done arbitrarily,
depending on network topology. This arbitrariness is a source of
vulnerability. We replace it with explicit randomness, which is at the
control of the protocol. The change does not introduce executions that were
not possible with the old protocol.
3. Complete backward compatibility:
Any subset of the miners can switch to the proposed protocol.
4. Progressive improvement:
Each miner that adopts the change raises the threshold a little bit. The
threshold will reach 25% with universal adoption.
[-- Attachment #2: Type: text/html, Size: 3331 bytes --]
next reply other threads:[~2013-11-05 16:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 16:56 Ittay [this message]
2013-11-05 17:05 ` [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold 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
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='CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com' \
--to=ittay.eyal@cornell.edu \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=egs@systems.cs.cornell.edu \
--cc=gavin@bitcoinfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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