From: "Luke-Jr" <luke@dashjr.org>
To: Mike Koss <mike@coinlab.com>
Date: Mon, 4 Jun 2012 21:05:25 +0000
User-Agent: KMail/1.13.7 (Linux/3.2.12-gentoonestfix-intelwr; KDE/4.8.1; x86_64;
	; )
References: <201206030052.17128.luke@dashjr.org>
	<201206040204.57503.luke@dashjr.org>
	<CAErK2CjpSb=Rb+evWg+_fs0brBfTDe3_HM1z-an0picb_8tzpQ@mail.gmail.com>
In-Reply-To: <CAErK2CjpSb=Rb+evWg+_fs0brBfTDe3_HM1z-an0picb_8tzpQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201206042105.27064.luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Defeating the block withholding attack
Precedence: list

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.