MAD-HTLC : Because HTLC is Crazy-Cheap to Attack

Bad news first: It turns out that the security of hash time lock smart contracts (HTLC) relies on the good intentions of blockchain miners, or at least their short-sightedness. That’s right, it is based on the assumption that miners, those businesses that make money from energy, are altruistically naive.

Consequently, all systems that rely on HTLCs, on any blockchain, also require this assumption to work as intended. Unfortunately, HTLC is one of the most common smart contract primitives, and it is used pretty much everywhere – payment channel networks, atomic swaps, zero-knowledge contingent payments, cryptocurrency vaults and so forth.

These are not entirely breaking news though. The basic vulnerability is known to apply to the more-elaborate smart contract systems like Ethereum. However, we find that it also applies to the simpler ones, i.e., Bitcoin, and is much cheaper to execute than previously believed.

The good news: We present a solution – a plug-in replacement to HTLC that relies on miners’ rationality rather than their naivety. It is based on the infamous concept of mutual assured destruction (MAD). We call it MAD-HTLC. The idea is that in case of misbehavior, both parties get severely penalized. This removes the motivation for an attack.

We outline the attack and its analysis, and the MAD-HTLC solution. But first, a quick explainer on HTLC contracts – skip ahead if you are familiar.

HTLC

HTLC is set up by two parties: Alice and Bob, parameterized with a hash-lock and a timeout. The contract is initiated with cryptocurrency tokens, originally deposited by either Alice or Bob (according to the different use-cases).

To redeem the tokens, Alice or Bob have to submit transactions that satisfy the contract conditions. Alice’s transaction needs to provide a specific hash preimage to the hash-lock, and Bob’s transaction has to wait for the timeout to elapse.

Transactions offer fees to the miners that confirm them, and miners prioritize which transactions to maximize their received fees. Note that once a party gets the tokens the others cannot get them as well (i.e., no double spending).

The Attack

The attack takes place when Alice (the victim) tries to get the HTLC tokens by submitting her transaction. Bob (the attacker) responds with a transaction of his own that offers sufficiently-higher fees, incentivizing miners to prefer his transaction over Alice’s. Miners then simply wait for the timeout to elapse and include Bob’s transaction, resulting with Bob getting the HTLC tokens, miners getting higher fees, and Alice getting nothing.

We analyze this behavior as a game, played among Alice, Bob and the miners, all of whom strive to maximize their token balance. The game is played for the duration of the HTLC, and in each round one miner generates a block. We use the subgame perfect equilibrium solution concept – all participants are rational and aware of all other participants’ rationality, and they optimize their profit while considering the dynamic and sequential nature of the game.

Our analysis shows that Bob’s “sufficiently-higher fees” are actually quite low, meaning it is very cheap to deploy such an attack. In various instances of HTLCs deployed on Bitcoin, this attack could offer 5-figure ROI ratios, e.g., yield $10000 for a cost of $1.

Note that Bob incentivizes miners to act in his best interest, that is, he assumes miners make optimal transaction selection. Although this is not the case in general, the increasing stakes and opportunities (cf. the turmoil of a mysterious Ethereum user paying insanely high fees) will make optimization worthwhile. Indeed, we implement non-myopic optimizations by patching the standard Bitcoin Core client with merely 150 lines of code.

MAD-HTLC

Mutual Assured Destruction (MAD) is most-notably associated with the cold-war doctrine: Two opposing sides hold stocks of nuclear missiles. If either of them gets nuked, as its final action it retaliates by nuking the other side. Since each side knows of the other side’s response, neither of them attacks.

MAD is therefore a deterrence mechanism, which we apply in the design of MAD-HTLC. Specifically, we set it such that if Bob makes an attempt on Alice’s tokens he is guaranteed to lose.

The second concept in the heart of MAD-HTLC is considering miners as active participating entities in the smart contract. That is, we take advantage of the fact that miners are rational and act in their best interest.

The construction is based on the classical HTLC. We add a second hash-lock that Bob is required to solve, thus he is required to reveal another extra preimage with any transaction attempting to get the tokens. We also add another redeem option – any entity can get the tokens if it can solve both Alice’s and Bob’s hash-locks.

Now, if both Alice and Bob try to redeem a MAD-HTLC, they both have to reveal the respective hash preimages. The exposed preimages allow anyone to construct their own transaction and take the full MAD-HTLC amount. The miners are at an advantage here: Since they generate the blocks, they can create such transactions and get the money themselves, leading to both Alice and Bob receiving nothing – Mutual Assured Destruction.

If everyone behaves themselves, however, the operation of a MAD-HTLC is similar to that of HTLC. Other parties cannot steal the funds if Alice and Bob do not contend for the tokens. A game-theoretic analysis shows that correct behavior is the only subgame perfect equilibrium, making MAD-HTLC incentive compatible.

Our technical report includes the detailed analysis, as well as the MAD-HTLC Bitcoin script, pointers to main-net experiments (e.g., Alice redeems, Bob redeems, miner redeems), and details on our implementation of a Bitcoin Core patch for generic miner optimization.

Prior to this publication we conducted responsible disclosure with relevant parties of interest.

Follow @ItayTsabary
Follow @IttayEyal