Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SbhCK-0002Bc-NC for bitcoin-development@lists.sourceforge.net; Tue, 05 Jun 2012 00:00:32 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com designates 209.85.216.52 as permitted sender) client-ip=209.85.216.52; envelope-from=mike@coinlab.com; helo=mail-qa0-f52.google.com; Received: from mail-qa0-f52.google.com ([209.85.216.52]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SbhCJ-0003cj-RL for bitcoin-development@lists.sourceforge.net; Tue, 05 Jun 2012 00:00:32 +0000 Received: by qabj34 with SMTP id j34so2327074qab.11 for ; Mon, 04 Jun 2012 17:00:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=jp/dGCD2w6Cyjhv9yO3r3rcbOXS5kSSmk4XkxDwMDxw=; b=oaZfzGWkglDz3zNo93Jh1orskC9R3OdtzSSYGnRorv5OZbP3dJcLL7pTjBh3N+QgtJ gTZzNWK1Zxg9vwAn0e+PwIi2owcaw14PPCOW5Wod0STi/Y/BP2i2ynU7do3x+pqoDZHC x4npnvI4Fr7g75DTygK3V1rt96NREEo59BfVIsEH2ic4qlDjjI/Yg++ehzh2sVxd2Ds2 b/HW0Wxlx9gz+tADDTEMsrU8/OeQwTTf0v9F6K6+p9Rcju9pFc8vqBbSkJE5h7HAaTbQ WIvVRZ6pLiUsMo/1es2kA2p7FTHJr2UXIvxjOD07USOCF2Ysz34njZRTSsTJ7MO3RUdD T1UQ== MIME-Version: 1.0 Received: by 10.224.96.82 with SMTP id g18mr15193624qan.0.1338854426099; Mon, 04 Jun 2012 17:00:26 -0700 (PDT) Received: by 10.229.242.14 with HTTP; Mon, 4 Jun 2012 17:00:25 -0700 (PDT) In-Reply-To: <201206042105.27064.luke@dashjr.org> References: <201206030052.17128.luke@dashjr.org> <201206040204.57503.luke@dashjr.org> <201206042105.27064.luke@dashjr.org> Date: Mon, 4 Jun 2012 17:00:25 -0700 Message-ID: From: Mike Koss To: Luke-Jr Content-Type: multipart/alternative; boundary=20cf3074b3ec793ff504c1ae560a X-Gm-Message-State: ALoCoQmzoYMI3vEMdntTXoPniSlOaRdO238N3YcdCpVL6jauSSbrWN/FyZM+k0aIMg9FOAH8CoUy 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1SbhCJ-0003cj-RL Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Defeating the block withholding attack 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 Jun 2012 00:00:32 -0000 --20cf3074b3ec793ff504c1ae560a Content-Type: text/plain; charset=ISO-8859-1 I don't understand how your proposal will work for decentralized pools - can you explain it more concretely? What would the new block header look like? What is required for a share to to be earned? What is required for a block to be valid (added to Block Chain)? I don't think I understand what you mean by NextBlockCandidate. Perhaps a concrete example using difficulty 1.7 million would be instructive. On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr wrote: > On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote: > > As I understand the attack, the attacker gets compensated for the shares > > they earn, but the pool will be denied any valid blocks found. The > > attacker DOES NOT have access to the Bitcoins earned in the unreported > > block (only the mining pool has access to the Coinbase address and > > transactions in the block). > > With decentralized pools, the attacker does have access to the block, and > can > potentially submit it to the Bitcoin network directly bypassing the pool > if it > benefits them to do so. > > > So it's a zero-net-cost attack for the attacker (but no chance of making > a > > profit) to hurt the pool operator. > > Because of the above, there is a possibility an attacker can make a profit. > > > The only way to detect such an attack now is to look for "unlucky" > miners; > > at the current difficulty, you can't detect this cheat until many > millions > > of shares have been earned w/o a qualifying block. Since an attacker can > > also create many fake identities, they can avoid detection indefinitely > by > > abandoning each account after a million earned shares. > > There are other modes of detection, but nobody has bothered to implement > them > since attackers can easily do a simple workaround in an arms race. > > > I don't understand your proposal for fixing this. You would have to come > > up with a scheme where: > > > > - The miner can detect a qualifying hash to earn a share. > > - Not be able to tell if the hash is for a valid block. > > With my proposal, miners can find shares, but won't know if it's a valid > block > until the subsequent block is also found (that subsequent block might not > end > up being a real block in the big picture). > > > The way I would do this is to have a secret part (not shared with the > > miners) of a block that is part of the merkle hash, which is also used > in a > > secondary hash. Difficulty is then divide into two parts: the first, > > solved by the miner (earning a "share" - e.g., 1 in 4 Billion hashes). > And > > a second, solved by the pool (1 in Difficulty shares). A valid block > would > > have to exhibit a valid Share Hash AND a valid Pool Hash in order to be > > accepted. > > This only works for centralized pools, which are contrary to the health of > the > Bitcoin network. Decentralized pools cannot have a secret. > -- Mike Koss CTO, CoinLab (425) 246-7701 (m) A Bitcoin Primer - What you need to know about Bitcoins. --20cf3074b3ec793ff504c1ae560a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't understand how your proposal will work for decentralized pools = - can you explain it more concretely?

What would the new= block header look like?

What is required for a sh= are to to be earned?

What is required for a block to be valid (added to Bloc= k Chain)?

I don't think I understand what you = mean by NextBlockCandidate. =A0Perhaps a concrete example using difficulty = 1.7 million would be instructive.

On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr= <luke@dashjr.org> wrote:
On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:
> As I understand the attack, the attacker gets compensated for the shar= es
> they earn, but the pool will be denied any valid blocks found. =A0The<= br> > attacker DOES NOT have access to the Bitcoins earned in the unreported=
> block (only the mining pool has access to the Coinbase address and
> transactions in the block).

With decentralized pools, the attacker does have access to the block,= and can
potentially submit it to the Bitcoin network directly bypassing the pool if= it
benefits them to do so.

> So it's a zero-net-cost attack for the attacker (but no chance of = making a
> profit) to hurt the pool operator.

Because of the above, there is a possibility an attacker can make a p= rofit.

> The only way to detect such an attack now is to look for "unlucky= " miners;
> at the current difficulty, you can't detect this cheat until many = millions
> of shares have been earned w/o a qualifying block. =A0Since an attacke= r can
> also create many fake identities, they can avoid detection indefinitel= y by
> abandoning each account after a million earned shares.

There are other modes of detection, but nobody has bothered to implem= ent them
since attackers can easily do a simple workaround in an arms race.

> I don't understand your proposal for fixing this. =A0You would hav= e to come
> up with a scheme where:
>
> - The miner can detect a qualifying hash to earn a share.
> - Not be able to tell if the hash is for a valid block.

With my proposal, miners can find shares, but won't know if it= 9;s a valid block
until the subsequent block is also found (that subsequent block might not e= nd
up being a real block in the big picture).

> The way I would do this is to have a secret part (not shared with the<= br> > miners) of a block that is part of the merkle hash, which is also used= in a
> secondary hash. =A0Difficulty is then divide into two parts: the first= ,
> solved by the miner (earning a "share" - e.g., 1 in 4 Billio= n hashes). =A0And
> a second, solved by the pool (1 in Difficulty shares). =A0A valid bloc= k would
> have to exhibit a valid Share Hash AND a valid Pool Hash in order to b= e
> accepted.

This only works for centralized pools, which are contrary to the heal= th of the
Bitcoin network. Decentralized pools cannot have a secret.



--
Mike KossCTO, CoinLab
(425) 246-7701 (m)

A Bitcoin P= rimer=A0- What you need to know about Bitcoins.

--20cf3074b3ec793ff504c1ae560a--