From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B6B84FAE for ; Mon, 28 Dec 2015 19:35:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CF7CA142 for ; Mon, 28 Dec 2015 19:35:34 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id bx1so121017436obb.0 for ; Mon, 28 Dec 2015 11:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multipool-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dhi2s1E7xr+y6e4nHioSe5bN+j8EWZD7SdUBRMHFp0w=; b=c7GgITCrTH8UimnHAYD6o2ZaCz6SAqs6l+ZZD2cC20Tdb7739el/fM2XAOcztvRMPM XDNFdRIbBL43bSxiHr+0Zs73aKjChQnxn2QCvxUXJfxOcxkesZYq/KN1os8y/hhxYFOP X8bD9dFfg0/yjJ1VmP703pSnqNPWwWoMHLHq2sUpZjz7mySE3VGXQBZBx3tw6Z1RQgY4 TZA86lmbYnSne1XaW+1Fbww2yOdbsh/ZzhupG8WaHkz1oRqIHIssZK7l2kVpr/c5nrx/ BDSY5IdnJD7/myxaWq0tSjXYI44uoFEOLkfkas0RjEYbmlDeGHcbA3RBPpxfPsY5msBI BLoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dhi2s1E7xr+y6e4nHioSe5bN+j8EWZD7SdUBRMHFp0w=; b=jPeF979/l5gdEpIRuFjHP8iYtQE1H4Ido+cBKe6ImoxYS1SX8SaE5XBCts5MLUuCpv FEaxhYjwTnfF8eEeJtfLOKlH//z3T9jHULNjZLQvf+BxAdIFGHMsHL1cX1mnsCq74ln4 SZXmWjCaJNnR/MyyeMBPuFK2rNLVcXhRKqtANKO1jEkCFK+G3dmLQudQanFV0tY7duD2 s8elh9QH98ngaei5ZhvYXdznE6n15ZI2UtkdPmbdGv9ApEbkMyPAr4d4GLMF2X3xs8b8 ywOVjJrBixfVU3EJWgTAipjsa6Ds0649i/aAMIsXeVGYk3HVguRlf2m/oE54zvWqXSx0 aXGw== X-Gm-Message-State: ALoCoQnqMEOyjGFwSF5BI89kaAHJHp5j1R/V2mgOW5TZtiMhFmkpVoqTpifzDV2vMYNU0mH9YplNlF5iB32gn4YY4c7nBw2SXg== MIME-Version: 1.0 X-Received: by 10.182.138.103 with SMTP id qp7mr5480073obb.74.1451331334299; Mon, 28 Dec 2015 11:35:34 -0800 (PST) Received: by 10.182.200.166 with HTTP; Mon, 28 Dec 2015 11:35:34 -0800 (PST) In-Reply-To: References: <20151219184240.GB12893@muck> <4882BD35-D890-4860-9222-5C23AEB6AE89@mattcorallo.com> <20151220044450.GA23942@muck> <20151228191228.GC12298@muck> Date: Mon, 28 Dec 2015 11:35:34 -0800 Message-ID: From: Multipool Admin To: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= Content-Type: multipart/alternative; boundary=e89a8ff1cbcaa1fa1b0527fa6828 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] We need to fix the block withholding attack X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 19:35:35 -0000 --e89a8ff1cbcaa1fa1b0527fa6828 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 28, 2015 at 11:30 AM, Emin G=C3=BCn 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=C3=BCn >> 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 --e89a8ff1cbcaa1fa1b0527fa6828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 28, 2015 at 11:30 AM, Emin G=C3=BCn Sirer <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:


On Mon, Dec 28, 2015 at 2:12 PM, P= eter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoun= dation.org> wrote:
Do you s= pecifically mean selfish mining as defined in Emin G=C3=BCn
Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significan= t
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 r= ight: we know that selfish mining is a guaranteed win
at 34%. We = do not know when exactly it begins to pay off. The more=C2=A0
con= solidated 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=C2=A0
at lower thresholds.

Exactly.
=C2=A0
Far more concerning i= s network propagation effects between large and
small miners.

On a related note, th= e Bitcoin-NG paper took a big step towards moving
these kinds of = concerns out of the realm of gut-feelings and wavy hands=C2=A0
in= to science. In particular, it introduced metrics for fairness (i.e. differe= ntial
rate in orphans experienced by small and large miners), has= h power=C2=A0
efficiency, as well as consensus delay.=C2=A0
=
=C2=A0
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.
= =C2=A0
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 pool= s.=C2=A0

This I dis= agree with -- if they know that they have been attacked, then there is ever= y reason to come forward with this information.

Fi= rst of all, it offers an explanation for poor profits (this is better than = unexplained poor profits).

Second of all, if one p= ool can be attacked then any pool can be attacked -- this is not a reason n= ot to mine on a particular pool.=C2=A0 If anything, it's a reason to di= versify hashrate among many pools.

--Adam
--e89a8ff1cbcaa1fa1b0527fa6828--