Smart Contracts Make Bitcoin Mining Pools Vulnerable

Abstract

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).

Appendices

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¹⁹.

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²⁰.

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²¹) 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.

Fig. 2.

Solidity code that force the attacker to attack.

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²².

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²³.

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.

Fig. 3.

Insurance for bitcoin double-spending.