From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdkPK-00072d-Tn for bitcoin-development@lists.sourceforge.net; Tue, 05 Nov 2013 17:27:14 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.172 as permitted sender) client-ip=209.85.217.172; envelope-from=stanga@gmail.com; helo=mail-lb0-f172.google.com; Received: from mail-lb0-f172.google.com ([209.85.217.172]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VdkPJ-00026o-QV for bitcoin-development@lists.sourceforge.net; Tue, 05 Nov 2013 17:27:14 +0000 Received: by mail-lb0-f172.google.com with SMTP id c11so6884136lbj.31 for ; Tue, 05 Nov 2013 09:27:06 -0800 (PST) X-Received: by 10.152.5.69 with SMTP id q5mr1009407laq.46.1383672426739; Tue, 05 Nov 2013 09:27:06 -0800 (PST) MIME-Version: 1.0 Sender: stanga@gmail.com Received: by 10.112.105.35 with HTTP; Tue, 5 Nov 2013 09:26:46 -0800 (PST) In-Reply-To: <20131105170541.GA13660@petertodd.org> References: <20131105170541.GA13660@petertodd.org> From: Ittay Date: Tue, 5 Nov 2013 12:26:46 -0500 X-Google-Sender-Auth: _fu2reVH2R_ApQf2pZ-RDDHyiKs Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=089e013d1b667b3d6c04ea7157d7 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stanga[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VdkPJ-00026o-QV Cc: Ittay , Gavin Andresen , =?ISO-8859-1?Q?Emin_G=FCn_Sirer?= , Bitcoin Dev Subject: Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold. X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:27:15 -0000 --089e013d1b667b3d6c04ea7157d7 Content-Type: text/plain; charset=ISO-8859-1 That sounds like selfish mining, and the magic number is 25%. That's the minimal pool size. Today the threshold is 0% with good connectivity. If I misunderstood your point, please elaborate. Ittay On Tue, Nov 5, 2013 at 12:05 PM, 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. > > > > > 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. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707 > --089e013d1b667b3d6c04ea7157d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That sounds like selfish mining, and the magic number is 2= 5%. That's the minimal pool size.=A0
Today the threshold is 0% with= good connectivity.=A0

If I misunderstood your poi= nt, please elaborate.=A0

Ittay=A0



On Tue, Nov 5, 2013 at 12:05 PM, = Peter Todd <pete@petertodd.org> 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<= br> 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.

--
'peter'[:-1]@pet= ertodd.org
0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707

--089e013d1b667b3d6c04ea7157d7--