The Block Withholding Attack should NOT be a concern. Here’s why.
A miner who finds a valid block can choose not to broadcast it. Say Alice is a miner and the block she just generated settles a dice roll. She wins if the coin lands on heads (H) but her newly discovered block landed on tails (T). She can broadcast this block, but then she’ll lose the coin flip. To have a chance of still winning the coin flip, she therefore better NOT broadcast the block.
A fair coin has a 50/50 chance of H or T. It’s trivial to make any newly discovered blockhash determine a coin flip with these probabilities. However, with the Withholding Attack, Alice skews these probabilities. If she controls 10% of the hashing power, these are the possibilities:
- 45% some other miner finds a H block
- 45% some other miner finds a T block
- 5% Alice finds a H block, so she wins, and naturally broadcasts
- 5% Alice finds a T block which she withholds
- The block that does get broadcast has 50% of being H or 50% of being T
Summing the probabilities, we see 45% + 5% + another 2.5% chance of H.
That’s 52.5% for heads vs 47.5% for tails.
The probability of H is a tiny bit higher since Alice can do this twice, thrice, or more if she’s on a lucky streak. I’ll anyway round up to to 53% for the remaining calculations.
The Miner’s Economic Dilemma
If Alice withholds a block, she loses the block reward. Currently that’s 12.5 BTC + roughly 1.5 BTC in fees. That’s around $16,000.
Her potential upside by doing so is that’s she may win the coin flip. The probability is still only 50% so withholding a block is worthwhile only if she can win more than $32,000 (twice a block reward).
The Opponent’s Dilemma
Bob can take the other side of the coin flip. He’s not a miner and his probability of winning is 47%. Whether he wants to play despite the slightly unfair coin, depends on his risk preferences.
The Economic Outcome
Slightly skewed probabilities will be partially offset by slightly better odds for the non-miner side. In the case of Bob, the odds may settle so that he gets 2.05 XCP if he wins for each 1 XCP he bets.
Still, some players will be deferred from participating. This is called a dead weight loss, and it happens everywhere in the economy. When there’s VAT (sales tax) on a product, some consumers will not buy and some retails won’t stick around. The same with tax on labor. Employment participation would be higher without it. With used cars there’s information asymmetry between buyer and seller but people do buy used cars nevertheless.
The dead weight loss from the withholding attack is insignificant
The likely use of XCP betting is not so much coin flips, but rather lotteries where one side gets a high payout with a low probability and the other side a low payout with a high probability. The former group is traditional lottery players or gamblers. These are risk seekers. The other side will need to escrow/risk large sums of XCP for a potential small gain. It’s likely these will be professionals who demand a positive expected return, i.e. they are risk averse.
The exact odds are set by these two groups interacting.
A common ground, an equilibrium, will be found. Remember that traditional lotteries have very low payouts. Isn’t less than 50% normal? Yet it’s a billion dollar industry.
Miner manipulation is a minuscule problem that may occur only after tens of thousands of USD worth are played in a single bet.
Another point - even if XCP betting reaches this level, and people do start worrying about this, they will simply spread their bets out on several blocks, so each one remains too small for profitable manipulation.
A related attack, with a simple solution, can happen if the oracle broadcasts the block’s timestamp. I’ll not go into details but the miner can basically set his timestamp ahead of real time (up to two hours is allowed), giving him more than 10x higher chances of doing a withholding attack. Still it’s only profitable if the sums involved are in the tens of thousands of USD.
But the solution is simple. The oracle is free to set whatever timestamp he pleases, so the automated XCP oracle should look at the previous block’s timestamp, not the last one where he gets randomness from.