public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chris Priest <cp368202@ohiou•edu>
To: "Emin Gün Sirer" <el33th4x0r@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
Date: Sat, 19 Dec 2015 23:39:07 -0800	[thread overview]
Message-ID: <CAAcC9ysejDQ8tyn_hhTQ_1ToKsM2f2rdhG4d1X3O5uuBj1X8NQ@mail.gmail.com> (raw)
In-Reply-To: <CAPkFh0vNECi1OmBwki+8NNAQbe6EG2FEE4RR5z=kYVLLDFHUXg@mail.gmail.com>

On 12/19/15, Emin Gün Sirer <el33th4x0r@gmail•com> wrote:
>
> Chris Priest is confusing these attacks with selfish mining, and further,
> his characterization of selfish mining is incorrect. Selfish Mining is
> guaranteed to yield profits for any pool over 33% (as a result, Nick
> Szabo has dubbed this the "34% attack") and it may pay off even
> below that point if the attacker is well-positioned in the network;
> or it may not, depending on the makeup of the rest of the pools
> as well as the network characteristics (the more centralized
> and bigger the other pools are, the less likely it is to pay off). There
> was a lot of noise in the community when the SM paper came out,
> so there are tons of incorrect response narrative out there. By now,
> everyone who seems to be Bitcoin competent sees SM as a
> concern, and Ethereum has already adopted our fix. I'd have hoped
> that a poster to this list would be better informed than to repeat the
> claim that "majority will protect Bitcoin" to refute a paper whose title
> is "majority is not enough."

http://www.coindesk.com/bitcoin-mining-network-vulnerability/

just sayin'...

But anyways, I agree with you on the rest of your email. This is only
really an attack from the perspective of the mining pool. From the
user's perspective, its not an attack at all. Imagine your aunt who
has bitcoin on a SPV wallet on her iphone. Does she care that two
mining pools are attacking each other? Its has nothing to do with her,
and it has nothing to do with most users or bitcoin either. From the
bitcoin user's perspective, the mining pool landscape *should* be
constantly changing. Fixing this "attack" is promoting mining pool
statism. Existing mining pools will have an advantage over up and
coming mining pools. That is not an advantage that is best for bitcoin
from the user's perspective.

Now, on the other hand, if this technique is used so much, it results
in too many pools getting shut down such that the difficulty starts to
decrease, *then* maybe it might be time to start thinking about fixing
this issue. The difficulty dropping means the security of the network
is decreased, which *does* have an effect on every user.


  reply	other threads:[~2015-12-20  7:39 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
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 [this message]
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=CAAcC9ysejDQ8tyn_hhTQ_1ToKsM2f2rdhG4d1X3O5uuBj1X8NQ@mail.gmail.com \
    --to=cp368202@ohiou$(echo .)edu \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=el33th4x0r@gmail$(echo .)com \
    /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