public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•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: Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
Date: Tue, 5 Nov 2013 12:14:45 -0500	[thread overview]
Message-ID: <20131105171445.GA13710@petertodd.org> (raw)
In-Reply-To: <20131105170541.GA13660@petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
> 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.
> 
> <snip>
> 
> > 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.
> 
> Credit goes to Gregory Maxwell for pointing this out, but the random
> choice solution does in fact introduce a vulnerability in that it
> creates incentives for pools over a certain size to withhold blocks
> rather than immediately broadcasting all blocks found.
> 
> The problem is that when the pool eventually choses to reveal the block
> they mined, 50% of the hashing power switches, thus splitting the
> network. Like the original attack this can be to their benefit. For
> pools over a certain size this strategy is profitable even without
> investing in a low-latency network; Maxwell or someone else can chime in
> with the details for deriving that threshold.
> 
> I won't get a chance to for a few hours, but someone should do the
> analysis on a deterministic switching scheme.

Oh, and I don't want to give the wrong impression: there's no need to
rush to get this problem fixed. Even if someone wanted to launch an
attack right now, with a fair amount of resources, there's a lot of
counter-measures based on human intervention that can definitely stop
the attack in the short-term; what's needed is at worst moderate-term,
and much more likely a long-term approach. In addition, keep in mind
that this attack is very easy to detect, so if one is actually launched
we will know immediately and can start taking direct counter-measures at
that time.

That Gregory Maxwell so quickly identified a flaw in this proposed
solution suggests we should proceed carefully.

It'd be good to do a test of this attack, as well as possible solutions,
on testnet to better explore it and possible counter-measures.

-- 
'peter'[:-1]@petertodd.org
000000000000000a03ea8c90161a275ee63d077ec35c1b582c77934c0be12a02

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2013-11-05 17:15 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 [this message]
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=20131105171445.GA13710@petertodd.org \
    --to=pete@petertodd$(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