From: Chris Priest <cp368202@ohiou•edu>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
Date: Sat, 19 Dec 2015 19:34:26 -0800 [thread overview]
Message-ID: <CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com> (raw)
In-Reply-To: <20151219184240.GB12893@muck>
Block witholding attacks are only possible if you have a majority of
hashpower. If you only have 20% hashpower, you can't do this attack.
Currently, this attack is only a theoretical attack, as the ones with
all the hashpower today are not engaging in this behavior. Even if
someone who had a lot of hashpower decided to pull off this attack,
they wouldn't be able to disrupt much. Once that time comes, then I
think this problem should be solved, until then it should be a low
priority. There are more important things to work on in the meantime.
On 12/19/15, Peter Todd via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> At the recent Scaling Bitcoin conference in Hong Kong we had a chatham
> house rules workshop session attending by representitives of a super
> majority of the Bitcoin hashing power.
>
> One of the issues raised by the pools present was block withholding
> attacks, which they said are a real issue for them. In particular, pools
> are receiving legitimate threats by bad actors threatening to use block
> withholding attacks against them. Pools offering their services to the
> general public without anti-privacy Know-Your-Customer have little
> defense against such attacks, which in turn is a threat to the
> decentralization of hashing power: without pools only fairly large
> hashing power installations are profitable as variance is a very real
> business expense. P2Pool is often brought up as a replacement for pools,
> but it itself is still relatively vulnerable to block withholding, and
> in any case has many other vulnerabilities and technical issues that has
> prevented widespread adoption of P2Pool.
>
> Fixing block withholding is relatively simple, but (so far) requires a
> SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
> do this hard-fork in conjunction with any blocksize increase, which will
> have the desirable side effect of clearly show consent by the entire
> ecosystem, SPV clients included.
>
>
> Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block
> witholding attacks are a good thing, as in their model they can be used
> by small pools against larger pools, disincentivising large pools.
> However this argument is academic and not applicable to the real world,
> as a much simpler defense against block withholding attacks is to use
> anti-privacy KYC and the legal system combined with the variety of
> withholding detection mechanisms only practical for large pools.
> Equally, large hashing power installations - a dangerous thing for
> decentralization - have no block withholding attack vulnerabilities.
>
> 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
>
next prev parent reply other threads:[~2015-12-20 3:34 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-19 18:42 Peter Todd
2015-12-19 19:30 ` Bob McElrath
2015-12-19 20:03 ` jl2012
2015-12-20 3:34 ` Chris Priest [this message]
2015-12-20 3:36 ` Matt Corallo
2015-12-20 3:43 ` Chris Priest
2015-12-20 4:44 ` Peter Todd
2015-12-26 8:12 ` Multipool Admin
2015-12-27 4:10 ` Geir Harald Hansen
2015-12-28 19:12 ` Peter Todd
2015-12-28 19:30 ` Emin Gün Sirer
2015-12-28 19:35 ` Multipool Admin
2015-12-28 19:33 ` Multipool Admin
2015-12-28 20:26 ` Ivan Brightly
2015-12-29 18:59 ` Dave Scotese
2015-12-29 19:08 ` Jonathan Toomim
2015-12-29 19:25 ` Allen Piscitello
2015-12-29 21:51 ` Dave Scotese
2015-12-20 3:40 ` jl2012
2015-12-20 3:47 ` Chris Priest
2015-12-20 4:24 ` jl2012
2015-12-20 5:12 ` Emin Gün Sirer
2015-12-20 7:39 ` Chris Priest
2015-12-20 7:56 ` Emin Gün Sirer
2015-12-20 8:30 ` Natanael
2015-12-20 11:38 ` Tier Nolan
2015-12-20 12:42 ` Natanael
2015-12-20 15:30 ` Tier Nolan
2015-12-20 13:28 ` Peter Todd
2015-12-20 17:00 ` Emin Gün Sirer
2015-12-21 11:39 ` Jannes Faber
2015-12-25 11:15 ` Ittay
2015-12-25 12:00 ` Jonathan Toomim
2015-12-25 12:02 ` benevolent
2015-12-25 16:11 ` Jannes Faber
2015-12-26 0:38 ` Geir Harald Hansen
2015-12-28 20:02 ` Peter Todd
2015-12-26 8:23 ` Eric Lombrozo
2015-12-26 8:26 ` Eric Lombrozo
2015-12-26 15:33 ` Jorge Timón
2015-12-26 17:38 ` Eric Lombrozo
2015-12-26 18:01 ` Jorge Timón
2015-12-26 16:09 ` Tier Nolan
2015-12-26 18:30 ` Eric Lombrozo
2015-12-26 19:34 ` Jorge Timón
2015-12-26 21:22 ` Jonathan Toomim
2015-12-27 4:33 ` Emin Gün Sirer
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='CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com' \
--to=cp368202@ohiou$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--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