[Bitcoin-development] Fwd: Defeating the block withholding attack

Watson Ladd wbl at uchicago.edu
Sun Jun 3 03:40:41 UTC 2012

On Sat, Jun 2, 2012 at 7:52 PM, Luke-Jr <luke at dashjr.org> wrote:
> Analysis, comments, constructive criticism, etc welcome for the following:
> ==Background==
> At present, an attacker can harm a pool by intentionally NOT submitting shares
> that are also valid blocks. All pools are vulnerable to this attack, whether
> centralized or decentralized and regardless of reward system used. The
> attack's effectiveness is proportional to ratio of the attacker's hashrate to
> the rest of the pool.
This attack has an obvious signature: getting outworked on the same
block as the pool was trying to verify, and always by the same person.
> There are obvious solutions that can be used to defeat this attack on
> centralized pools. For example, including a secret in the coinbase transaction
> that is accepted by the network as a partial preimage proof-of-work. All these
> solutions require changes to Bitcoin's proof-of-work acceptance terms, and
> since centralized pools can be harmful to the network's security, these rule
> changes are not likely to gain enough acceptance among the greater Bitcoin
> community.
> ==Proposed Solution==
> Please comment on the viability of this new proof-of-work algorithm, which I
> think should be viable for even decentralized pools:
> Blocks are accepted at a lower difficulty N (choosable by the pool; eg, the
> share difficulty) iff they are submitted with a candidate for the next block
> and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficulty M.
> The relationship between M and N must be comparable to the normal network
> difficulty; details on the specifics of this can be figured out later, ideally
> by someone more qualified than me. M and N must be chosen prior to searching
> for the block: it should be safe to steal some always-zero bytes from the
> prevblock header for this.
So the goal is to prevent the attacker double-dipping by submitting
cycles to the pool, which if he
found a correct answer he could submit himself. I don't see how this
does that: if he finds a valid
block he finds a valid block. Only if the operator has a secret is
this prevented.
> This algorithm should guarantee that every share has an equal chance of being
> a valid block at the time it is found, and that which ones are actually blocks
> cannot be known until the subsequent block is found. Thus, attackers have no
> way to identify which shares to withhold even while they have full knowledge
> of the shares/blocks themselves.
This further delays the finalization of a transaction. That's not a good thing.
> ==Backward Compatibility==
> Obviously, this change creates a hard-fork in the blockchain. I propose that
> if it solves the block withholding risk, the gain is sufficient that the
> community may approve a hard-fork to take place 1-2 years from consensus.
> Since mining continues to use a double-SHA256 on a fixed 80 byte header,
> existing miners, FPGAs, etc should work unmodified. Poolservers will need to
> adapt significantly.
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

More information about the bitcoin-dev mailing list