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 07A36CE7 for ; Sun, 20 Dec 2015 15:30:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5648130 for ; Sun, 20 Dec 2015 15:30:09 +0000 (UTC) Received: by mail-io0-f178.google.com with SMTP id 186so135388998iow.0 for ; Sun, 20 Dec 2015 07:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=HPmtuP1YVgT0Nz/9xGtzmqFJJLwktl3oVQAMOmTeT8g=; b=p5LrfApNyPUSBDto9I1L+yvK0X2bIeVW+mJP6KQUc3GxU9l1Vo9u4chpRevkCQ0BA8 1m9eQDVht+VndwqOyCP21C1JVXxPZiQ+354eOt4Kv50PCnaY3aSwl/oTpvTwsJzeAlwc jtmbZMYBAfYg7yJaW7+M3j1utpFKUifBCwUKSqmz+4R88EKjAl17u0k3kwN5OYWRYC9x qI6l2l3SMAsUhYUEVkuRS9AqjrlCJZNdKjFHybpPxcxgYcA6AglkTzGmvAJluCYr89zT 7l4fYdvN2QUCUbnPCkn4tkZSl/tU3yhMNi0DCNxxI/B45Nbp2xnBuw1gN64KQO8lYvVl 13/w== MIME-Version: 1.0 X-Received: by 10.107.153.79 with SMTP id b76mr18171985ioe.71.1450625409190; Sun, 20 Dec 2015 07:30:09 -0800 (PST) Received: by 10.79.77.75 with HTTP; Sun, 20 Dec 2015 07:30:09 -0800 (PST) In-Reply-To: References: <20151219184240.GB12893@muck> <219f125cee6ca68fd27016642e38fdf1@xbt.hk> Date: Sun, 20 Dec 2015 15:30:09 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1140f7e0378f410527560c64 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Sun, 20 Dec 2015 15:30:10 -0000 --001a1140f7e0378f410527560c64 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 20, 2015 at 12:42 PM, Natanael wrote: > If total difficulty is X and the ratio for full blocks to candidate blocks > shared with the pool is Y, then the candidate block PoW now has to meet X/Y > while hashing the candidate block PoW + the pool's commitment hash must > meet Y, which together makes for X/Y*Y and thus the same total difficulty. This gives the same total difficulty but miners are throwing away otherwise valid blocks. This means that it is technically a soft fork. All new blocks are valid according to the old rule. In practice, it is kind of a hard fork. If Y is 10, then all upgraded miners are throwing away 90% of the blocks that are valid under the old rules. >From the perspective of non-upgraded clients, the upgraded miners operate at a 10X disadvantage. This means that someone with 15% of the network power has a majority of the effective hashing power, since 15% is greater than 8.5% (85% * 0.1). The slow roll-out helps mitigate this though. It gives non-upgraded clients time to react. If there is only a 5% difference initially, then the attacker doesn't get much benefit. The main differences are that there's a public key identifier the miners > are told about in advance and expect to see in block templates, and that > that now the pool has to publish this commitment value together with the > block that also contains the commitment hash, and that this is verified > together with the PoW. I don't think public keys are strictly required. Registering them with DNSSEC is way over the top. They can just publish the key on their website and then use that for their identity. --001a1140f7e0378f410527560c64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Dec 20, 2015 at 12:42 PM, Natanael <natanael.l@gmail.com= > wrote:
If total difficulty is X and the ratio for full blocks= to candidate blocks shared with the pool is Y, then the candidate block Po= W now has to meet X/Y while hashing the candidate block PoW + the pool'= s commitment hash must meet Y, which together makes for X/Y*Y and thus the = same total difficulty.

This gives the same total difficulty but miners= are throwing away otherwise valid blocks.

This means that it is technically a soft fork.=C2=A0 All new blocks= are valid according to the old rule.
<= br>
In practice, it is kind of a hard fork.=C2=A0 If Y is 10, then all= upgraded miners are throwing away 90% of the blocks that are valid under t= he old rules.

From the perspective of non-upgraded clients, th= e upgraded miners operate at a 10X disadvantage.

This mea= ns that someone with 15% of the network power has a majority of the effecti= ve hashing power, since 15% is greater than 8.5% (85% * 0.1).

=
The slow roll-out helps mitigate this though.=C2=A0 It gives non-upgra= ded clients time to react.=C2=A0 If there is only a 5% difference initially= , then the attacker doesn't get much benefit.

The main differences are that there's a publ= ic key identifier the miners are told about in advance and expect to see in= block templates, and that that now the pool has to publish this commitment= value together with the block that also contains the commitment hash, and = that this is verified together with the PoW.=20

I don't think p= ublic keys are strictly required.=C2=A0 Registering them with DNSSEC is way= over the top.=C2=A0 They can just publish the key on their website and the= n use that for their identity.=C2=A0
--001a1140f7e0378f410527560c64--