We propose smart contracts that allows a wealthy adversary to rent existing hashing power and attack Nakamoto-style consensus protocols. Our bribery smart contracts highlight:
- The use of Ethereum’s uncle block reward to directly subsidise a bribery attack,
- The first history-revision attack requiring no trust between the briber and bribed miners.
- The first realisation of a Goldfinger attack, using a contract that rewards miners in one cryptocurrency (e.g. Ethereum) for reducing the utility of another cryptocurrency (e.g. Bitcoin).
This post provides an overview of the full paper (by Patrick McCorry, Alexander Hicks and Sarah Meiklejohn) which will be presented at the 5th Workshop on Bitcoin and Blockchain Research, held at this year’s Financial Cryptography and Data Security conference.
What is a bribery attack?
Fundamentally, a wealthy adversary (let’s call her Alice) wishes to manipulate the blockchain in some way. For example, by censoring transactions, revising the blockchain’s history or trying to reduce the utility of another blockchain.
But purchasing hardware up front and competing with existing miners is discouragingly expensive, and may require a Boeing or two. Instead, it may be easier and more cost-effective for Alice to temporarily rent hashing power and obtain a majority of the network’s hash rate before performing the attack.
Renting hashing power can be done in two ways, by using external services (e.g. AWS or specialised services) or by directly paying existing miners. For our attacks, we assume that Alice is attempting the latter, and does so without requiring bribed miners (which we’ll call Bob) to trust her.
Have a bribe, pay with uncle blocks
Our first contract, CensorshipCon, illustrates two interesting insights.
First, it demonstrates how the uncle block reward in Ethereum can directly subsidise Alice, and maybe even earn her a profit. This simply requires all bribed miners to pursue an uncle block mining strategy.
Second, all miners can continue mining in Ethereum to protect its computational weight while giving Alice full control of the blockchain. This works as long as Alice has more mining power than the honest miners. The lower bound on her required portion of the network’s hashrate she requires to outweigh the honest miners and maximise the network’s subsidy is only 25%.
The takeaway is that by implementing a variation of the GHOST protocol and including an additional uncle block reward; the consensus protocol now provides a means to directly support a subsidised bribery attack.
One briber can change the history of the blockchain
Our second contract, HistoryRevisionCon, is the first bribery contract that allows Alice to enforce the exact conditions that must be satisfied by a new fork. Unlike previous history-revision bribery attacks, Alice and Bob are only required to trust the contract and not each other.
The underlying idea behind this bribery attack is that Alice can publish a transaction that creates the HistoryRevisionCon contract (with a deposit), which Bob is required to include this transaction in his first bribed block. Afterwards the contract verifies that it was included at the correct height (e.g. block 100), and that the state of other contracts within the blockchain meets its expectation (e.g. the parity-wallet bug fix). If these conditions are satisfied, the contract will send a bribe to the block’s coinbase address (i.e. the bribed miner’s address). Future bribed miners can then simply invoke the contract in every bribed block to claim their reward.
As the contract can do all require checks for the briber (i.e. the forking conditions) and is auditable by the bribee (to check that a bribe will be released as promised), there is no requirement for them to trust each other.
Auric Goldfinger: No, Mr. Bitcoin, I expect you to die!
Our third contract, GoldfingerCon, is the first contract which aids an attack aiming to reduce the utility of a competing cryptocurrency.
We consider the case of a wealthy adversary wanting to reduce the utility of Bitcoin. The simplest approach is to reward miners for mining empty blocks, such that the network will no longer confirm new transactions.
Remarkably, there is a subtle technical (and gas-efficient) trick to check whether a block in Bitcoin is empty. Our contract checks whether the coinbase transaction hash has replaced the merkle tree root in the empty block’s header. If that is the case, the block has no transactions and this can be verified in the smart contract for around $0.50 per Bitcoin block.
Miners invest $$ in hardware; so surely they would never do that!
The community have so far not considered bribery attacks as practical due to their public and semi-trusted nature. For in-band style bribery where the miner is rewarded with coins of the attacked cryptocurrency, miners are unlikely to accept bribes as it could lower the value of their reward, but this may not always be the case. A possible use case could be a fail-safe for the Parity wallet bug which locked over 519k ether. The history-revision contract could be used to reward miners “unlocking” the wallet and accepting a portion of the coins as the bribe – which may be considered as acceptable by a significant portion of the community.
On the other hand, there is growing sentiment in the Bitcoin community that may facilitate a Goldfinger-style attack. Threats to “attack” minority forks have been made in the past:
“We have prepared $100 million USD to kill the small fork of CoreCoin,
no matter what proof of work algorithm, sha256 or scrypt or X11 or any other GPU algorithm. Show me your money. We very much welcome a CoreCoin change to POS.”
Zhuoer, founder of BTC.TOP
Common ways to debunk this style of attack by the Bitcoin community is to threaten a change in the Proof-of-Work algorithm, making the miners hardware redundant. Care must be taken though as this threat is only credible if there is no other cryptocurrency of significant value that also relies on the same Proof-of-Work algorithm. This would also open Bitcoin to GPU mining which is significantly easier to rent than ASIC hardware.
Future work
Improvements to the type of attack presented here could by answering the following questions:
- What are the best strategies for ramping up the attack in order to achieve a majority of the hashrate?
- What is the impact of selfish mining strategies in combination with bribery attacks for attacking and defending the network?
- Can these bribery contracts be used in a proof-of-stake setting and is there any fundamental differences in the style of bribery?
Most importantly, we believe that designers of Nakamoto-style consensus protocols should begin considering bribery attacks as part of their threat model – especially with the growing sentiments from wealthy participants in the community.