From: Multipool Admin <admin@multipool•us>
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: Mon, 28 Dec 2015 11:35:34 -0800 [thread overview]
Message-ID: <CAP3QyGKLa_Vf+f82RbNAYz=RP0ion4sqvj19Pqjr9v5taeo4pw@mail.gmail.com> (raw)
In-Reply-To: <CAPkFh0vY7sSFJxAnYSWgPszY6kAjcfDBR7cPn0ptL9yc-OtFdg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]
On Mon, Dec 28, 2015 at 11:30 AM, Emin Gün Sirer <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Do you specifically mean selfish mining as defined in Emin Gün
>> Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant
>> issue in a scenario - one malicious miner with >30% hashing power -
>> where you're already very close to the margins anyway; the difference
>> between a 50% attack threshold and a 30% attack threshold isn't very
>> significant.
>>
>
> This is not quite right: we know that selfish mining is a guaranteed win
> at 34%. We do not know when exactly it begins to pay off. The more
> consolidated and centralized the other mining pools, the less of a threat
> it is below 34%; the more decentralized, the more likely it is to pay off
> at lower thresholds.
>
Exactly.
> Far more concerning is network propagation effects between large and
>> small miners.
>
>
> On a related note, the Bitcoin-NG paper took a big step towards moving
> these kinds of concerns out of the realm of gut-feelings and wavy hands
> into science. In particular, it introduced metrics for fairness (i.e.
> differential
> rate in orphans experienced by small and large miners), hash power
> efficiency, as well as consensus delay.
>
>
>> For that class of issues, if you are in an environemnt
>> where selfish mining is possible - a fairly flat, easily DoS/sybil
>> attacked network topology - the profitability difference between small
>> and large miners even *without* attacks going on is a hugely worrying
>> problem.
>
>
> Indeed, there is a slight, quantifiable benefit to larger pools. Which is
> why
> we need to be diligent about not letting pools get too big.
>
>
>> Note though that Eligius is *not* the only pool to have had problems
>>
> with block withholding, though AFAIK Eligius is the only one who has
>> gone on record so far. (as I said in my original post, I'm relaying
>> information given to me under condition of confidentiality)
>>
>
> I can see why they don't want to go public with this: it means that they
> are less profitable than other pools.
>
This I disagree with -- if they know that they have been attacked, then
there is every reason to come forward with this information.
First of all, it offers an explanation for poor profits (this is better
than unexplained poor profits).
Second of all, if one pool can be attacked then any pool can be attacked --
this is not a reason not to mine on a particular pool. If anything, it's a
reason to diversify hashrate among many pools.
--Adam
[-- Attachment #2: Type: text/html, Size: 4374 bytes --]
next prev parent reply other threads:[~2015-12-28 19:35 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 [this message]
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='CAP3QyGKLa_Vf+f82RbNAYz=RP0ion4sqvj19Pqjr9v5taeo4pw@mail.gmail.com' \
--to=admin@multipool$(echo .)us \
--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