From: Adam Back <adam@cypherspace•org>
To: 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: [Bitcoin-development] comments on selfish-mining model (Re: BIP proposal - patch to raise selfish mining threshold.)
Date: Thu, 7 Nov 2013 21:05:34 +0100 [thread overview]
Message-ID: <20131107200534.GA27068@netbook.cypherspace.org> (raw)
In-Reply-To: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com>
(Talking about the paper, not the BIP). With regard to racing the other
winner which catches up when private pool length=1:
i) the model does not appear to take into account that when another pool
goes on to mine a block, and the attacker publishes their selfishly-withheld
block, the selfish pool will not be able to change the existing winners
mind. This is not insignificant as the pools have 30%, 20%, 15%, 7% etc.
ii) The miners already have an incentive, as other big bitcoin processors,
to maintain fast, secure and redundant links to other significant miners.
The attacker is giving up a large proportion of their winnings from the
times that they win at all. Say the attacker IS the 30% pool, when he wins
and waits for someone else to win, > 80% of the network is pool mined, so
there is a good chance that the other winner individually represents a
non-negligible proportion of the network or a sufficiently well connected
portion of the network that the attacker will be unable to race them to
publication with a useful proportion of the network.
iii) Also broadcast is not instantaneous, lets say network propagation takes
10 seconds; a big proportion of the time, the actual mining times will be
more than 5 seconds apart so that by the time the selfish miner learns of
the block, much of the network will already have accepted it block as first.
iv) Even within the 10 seconds ambiguity period, the more powerful miner
will tend statistically to come first, and so reach a bigger portion of the
network, as well as having a stronger incentive to maintain links as in ii).
These four factors erode the achievable \gamma parameter. I suspect it
unlikely \gamma>0.5 would be achievable, putting the profitable threshold
\alpha in 25% - 33%. (And assuming whatever techniques to reduce latency
are used by the selfish pools can be used by other pools.)
Your main result that even with \gamma=0 (if you dont win any races) that
you still win once the selfish pool reaches 33% is an important new
indication, which needs further consideration. (And you could expect to win
some percentage \gamma>0 even with the factors I mention, and full
implementation of the same latency reduction techniques in all moderate
sized miners, selfish and normal).
It is also not clear what will happen if multiple selfish miners compete
with each other. A selfish miner cooperating as a peer to increase
percentage runs risk of mutual sabotage - he has to announce his private
block to his co-conspirator, and the co-conspirator may publish, or collude
with another non-selfish miner.
Your supposition is there is a profit motive to collude. However there are
other profit motives in bitcoin that are not exercised - for example there
were for sometime 2 pools that had excess of 50% power, and yet this was not
abused for double spending. Of course increasing profit by a new mining
strategy is not theft as double spending which has a clear loser. Miners
even exercised restraint and volutarily avoided growing over 50%.
As others have I think said by now analysis is welcome. It seems that Peter
Todd may have observed the same or something similar wrt miner incentives
some months ago, though it wasnt as widely read nor formally verified.
It might be useful to release the source for your simulator if that is open
to you.
In my opinion a constructive direction for reducing centralization risks is
to try to reduce the use of and motivation for pools. Even at <51% per pool
there is (probabilistic) miner risk in double-spends. And there is risk
that the large miners evolve to become a defacto policy enforcement point
for policies not aligned with user interests, or with fungibility of bitcoin
which itself presents another kind of risk (defacto reduced fungibility
should this arise would also be bad for bitcoin).
Also without even having mining power, there is scope to network hacking (eg
of routers in front of miners) to influence the mining profit, and even
double spend. As I mentioned large miners have an incentive to maintain
secure redudant links (probably some links using Tor for blocks) as a
counter-measure.
Adam
On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
> Hello,
> Please see below our BIP for raising the selfish mining threshold.
> Looking forward to your comments.
prev parent reply other threads:[~2013-11-07 20:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 16:56 [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold 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
2013-11-05 22:49 ` Ittay
2013-11-07 20:05 ` Adam Back [this message]
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=20131107200534.GA27068@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--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 \
/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