[Bitcoin-development] Defeating the block withholding attack
mike at coinlab.com
Tue Jun 5 00:00:25 UTC 2012
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 <luke at 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 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
> 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
> > 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"
> > at the current difficulty, you can't detect this cheat until many
> > of shares have been earned w/o a qualifying block. Since an attacker can
> > also create many fake identities, they can avoid detection indefinitely
> > abandoning each account after a million earned shares.
> There are other modes of detection, but nobody has bothered to implement
> 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
> until the subsequent block is also found (that subsequent block might not
> 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).
> > a second, solved by the pool (1 in Difficulty shares). A valid block
> > 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
> Bitcoin network. Decentralized pools cannot have a secret.
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev