Smart Contracts Make Bitcoin Mining Pools Vulnerable

Despite their incentive structure flaws, mining pools account for more than 95% of Bitcoin’s computation power. This paper introduces an attack against mining pools in which a malicious party pays pool members to withhold their solutions from their pool operator. We show that an adversary with a tiny amount of computing power and capital can execute this attack. Smart contracts enforce the malicious party’s payments, and therefore miners need neither trust the attacker’s intentions nor his ability to pay. Assuming pool members are rational, an adversary with a single mining ASIC can, in theory, destroy all big mining pools without losing any money (and even make some profit).

1. 1.

   https://www.bitmaintech.com/productDetail.htm?pid=0002016052907243375530DcJIoK0654.

2. 2.

   https://en.bitcoin.it/wiki/Block_hashing_algorithm.

3. 3.

   https://blockchain.info/charts/difficulty.

4. 4.

   https://slushpool.com/help/#!/first-aid/troubleshooting.

5. 5.

   Our analysis is valid even for much larger difficulty levels.

6. 6.

   http://www.coindesk.com/price/.

7. 7.

   https://www.bitmaintech.com/.

8. 8.

   https://en.bitcoin.it/wiki/Comparison_of_mining_pools.

9. 9.

   The miner would also get the standard share reward, however, these are typically smaller by a factor of over \(10^9\).

10. 10.

    http://p2pool.org/stats/.

11. 11.

    http://ethereum.stackexchange.com/questions/872/what-is-the-cost-to-store-1kb-10kb-100kb-worth-of-data-into-the-ethereum-block.

12. 12.

    https://blockchain.info/charts/blocks-size.

13. 13.

    To prevent cases where it would be profitable to find \(b_3\) for the purposes of selfish mining, we could ask for a chain of blocks that extend \(b_2\) rather than only a single block.

14. 14.

    https://en.bitcoin.it/wiki/Script.

15. 15.

    We make the assumption that orphan blocks are also publicly visible, e.g., see https://blockchain.info/orphaned-blocks.

16. 16.

    https://blockchain.info/charts/n-orphaned-blocks?timespan=1year.

17. 17.

    https://blockchain.info/orphaned-blocks.

18. 18.

    https://en.bitcoin.it/wiki/Comparison_of_mining_pools.

19. 19.

    E.g., see line 110 in https://raw.githubusercontent.com/slush0/stratum-mining/38637575c8c253aba18f95dffd25c49ca6d0434b/lib/block_template.py.

20. 20.

    https://en.bitcoin.it/wiki/Pay_to_script_hash.

21. 21.

    https://www.coingecko.com/en/price_charts/ethereum/usd.

22. 22.

    To mitigate the incentive for the attacker to seize the collaterals and give it to a Sybil identity, we can change the contract so it would give only half of the collateral and the other half would be destroyed (e.g., would be sent to address 0x000...000).

23. 23.

    A naive approach that only search for common inputs and check that \(tx \ne tx'\) would fail due to Bitcoin’s transaction malleability issue [23].

We thank our shepherd, Iddo Bentov, for useful discussions and the anonymous reviewers of an earlier draft of this paper for helpful feedback.

Authors and Affiliations

1. The Hebrew University of Jerusalem, Jerusalem, Israel

   Yaron Velner

2. TrueBit Foundation, Tel Aviv, Israel

   Jason Teutsch

3. School of Computing, National University of Singapore, Singapore, Singapore

   Loi Luu

Corresponding author

Correspondence to Loi Luu .

Editors and Affiliations

1. Leibniz Universität Hannover, Hannover, Germany

   Michael Brenner

2. New Jersey Institute of Technology, Newark, New Jersey, USA

   Kurt Rohloff

3. New York University, New York, New York, USA

   Joseph Bonneau

4. University of Illinois at Urbana-Champaign, Urbana, Illinois, USA

   Andrew Miller

5. University of Luxembourg, Luxembourg, Luxembourg

   Peter Y.A. Ryan

6. University of Melbourne, Parkville, Victoria, Australia

   Vanessa Teague

7. University of Stirling, Stirling, United Kingdom

   Andrea Bracciali

8. University of Trento, Trento, Italy

   Massimiliano Sala

9. University of Trento, Trento, Italy

   Federico Pintore

10. Agari Inc., San Mateo, California, USA

    Markus Jakobsson

A Bitcoin Implementation

In this section, we refine the interactive protocol from Sect. 4.2 for use in Bitcoin. The security of our Bitcoin protocol relies on the following two assumptions which we will later relax in Appendix B:

• The attacker always wants to attack. That is, he is always willing to pay a predefined amount for a valid proof of block withholding.

• The withholder is willing to withhold the block in return for a Bitcoin zero-confirmation payment.

The first assumption is reasonable as the attack is profitable. However, it is not trivial, as malicious parties could dishonestly declare their intentions to make such an attack but never collaborate with the withholder. Such behavior might be expected, e.g., by pool operators who wish to undermine trust between attackers and withholders. The second assumption could be justified as zero confirmation double spending is not trivial to perform [21]. Our protocol would allow the withholder to wait for a short period of time before deciding on his actions. In this period of time the transaction would propagate to the majority of the network, and the odds for double spending could be evaluated and bounded from above, e.g., via [22]. If odds are, for example, less than 50%, then it is enough to double the offered reward in order to incentivize the withholder. In Sect. B we will introduce Ethereum smart contracts that enforce our assumptions. That is, the contracts would compensate the withholder (in ether currency) if the attacker does not collaborate with the protocol or performs double spending.

We are now ready to introduce the protocol.

• Initially, the withholder submits (off-chain) a 32-byte chunk of data b and his Bitcoin public key.

• The attacker computes \({{\mathrm{sha256}}}(b)\) and rejects the submission if: (i) the difficulty level is not sufficient; or (ii) \({{\mathrm{sha256}}}(b)\) corresponds to a block in the public blockchain; or (iii) b was already submitted in the past.

• (Otherwise) The attacker signs and sends the withholder a Bitcoin transaction t such that:

  • The attacker can redeem t with an input string \(b'\) that satisfies \({{\mathrm{sha256}}}(b') = b\).

  • The withholder can redeem t after T block epochs (provided that it was not already redeemed).

• The withholder submits t to the network, waits for it to propagate, withholds his block, and redeems t after T block epochs.

The correctness of the scheme follows by our two assumptions and by the arguments of the correctness proof of the protocol in Sect. 4.2. We note that in the last phase of the protocol, the withholder cannot afford to wait for a block confirmation. Indeed, a block confirmation occurs only after a new block is mined, and when this happens the withholder’s block becomes worthless as he can no longer submit it to his pool operator^{Footnote 19}.

An implementation of transaction t as a Bitcoin script is illustrated bellow.

Implementation with bitcoin script. Transaction t locking script is:

The buyer can redeem t with this unlocking script:

The seller can redeem t after sufficient enough time with this unlocking script:

We note that in order to make these transaction standard we use pay to script hash transactions^{Footnote 20}.

B Ethereum Contracts as Insurance

In this section, we describe two Ethereum smart contracts that eliminates the need for the assumptions we made in Appendix A. The contracts provides the following guarantee:

The withholder is either payed the promised amount in bitcoin or payed disproportional high value in ether currency.

Such guarantee should mitigate any concern from the withholder side, even if he has strong preference towards bitcoin payments. Indeed, either he gets payed with bitcoin or he receive high ether payment that compensates for his bitcoin preference.

We first describe how to mitigate the assumption that the attacker always wants to attack, and then describe an Ethereum insurance contract against Bitcoin double-spending. For the rest of the section we assume that 1,000 ether (approximately 10, 000 USD as of January 3, 2017^{Footnote 21}) are enough to compensate for any preference towards Bitcoin payment.

1.1 B.1 Forcing the Attacker to Attack

In this section we describe how an Ethereum contract (published by the attacker) can enforce the attacker to honestly execute his part in the protocol. We recall that the attacker’s role in the protocol is to publish a signed transaction t when a valid block withholding witness b is submitted, i.e., when a never before submitted block header with sufficient difficulty is submitted. The contract has four functions, namely, depositCollateral, submitWitness, submitTx and seizeCollateral.

• depositCollateral: in this function the attacker deposits 1,000 ether.

• submitWitness: in this function the withholder submits the witness b and his Bitcoin public key. The function checks that b was never submitted before and its difficulty is sufficient (i.e., \({{\mathrm{sha256}}}(b)\) is small enough), and records the current time.

• submitTx: in this function the attacker submits a signed transaction t and the contract verifies that the transaction is properly signed in the format as described in Appendix A.

• seizeCollateral: in this function the withholder can withdraw the 1, 000 ether if the attacker did not respond in time (or responded with invalid transaction).

See Fig. 2 for partial implementation of the contract. Intuitively, this contract enforces the attacker to post a signed Bitcoin transaction to the Ethereum blockchain (within a given time period T). Once published, the withholder can post it to the Bitcoin network and claim his payment in bitcoin currency. If the attacker decides not to post the transaction, then the withholder collects the collateral that serves as a compensation for the block withholding and for getting paid in ether.

Solidity code that force the attacker to attack.

Full size image

We note that the contract can serve as an insurance only when the balance is sufficient (i.e., when a collateral is deposited). Hence, the withholder should check the balance before participating in the scheme^{Footnote 22}.

1.2 B.2 Insurance Against Double-Spending

In this section, we introduce an Ethereum contract that serves as an insurance against Bitcoin double-spending scenarios. We use it to mitigate the zero-confirmation assumption for our Bitcoin implementation of the block withholding attack. The contract provides insurance for up to N simultaneous, double-spending operations of a single Bitcoin address. Formally, we say that a transaction tx is double-spent by address a if tx is signed by a and there exists another signed transaction \(tx'\) such that tx and \(tx'\) share at least one common input and differ by at least one output^{Footnote 23}.

The contract is illustrated in Fig. 3. In createInsurance function the owner of the bitcoin account deposits 1,000 ether for every insured double-spending operation. In the claimCompensation function, the victim submits the witness for double-spending and unlocking script for the controversial output, as a witness for being eligible for compensation. To prevent a Sybil attack, where the owner of the insured account claim N compensation units to himself, we could halve the compensation and destroy the remaining 500 ether.

Insurance for bitcoin double-spending.

Full size image

Reprints and permissions

© 2017 International Financial Cryptography Association

Policies and ethics