This article is also available on Gleb’s personal blog here.
In this article, we attempt to design smart contracts encouraging miners to withhold a certain transaction, to better understand how practical such smart contracts are.
Better understanding these contracts is relevant in the broad Bitcoin context, and for better understanding the security of time-sensitive Bitcoin protocols.
We start from trivial mempool spamming (not a smart contract), and go up to covenant-enabled multi-stage reward transactions.
Censorship resistance is a central property of Bitcoin. We even argue it is axiomatic that Bitcoin is good at resisting state control, and Bitcoin can’t be forced to censor a particular transaction.
However, what if Bitcoin miners are encouraged to ignore a particular transaction? Clearly, a party opposing a certain transaction could just outbid it w.r.t. limited block size. We call this, and other non-forcing ways to ignore a transaction, transaction withholdment (or TxWithhold), which should not be confused with (forced) censorship (although some research highlighted in Background would call this censorship).
Clearly, withholdment resistance is not axiomatic. At the same time, we believe that it is unlikely due to the following two observations:
- miners are driven by the Bitcoin price going up, and withholdment could trigger the price going down because it challenges the common understanding that Bitcoin transactions are more withholdment-resistant than they actually are;
- withholdment is hard to coordinate: it is either too expensive for the briber, or not interesting to miners.
Nonetheless, attempts to accomplish withholdment could be made, especially with the regulatory pressure (e.g., ChainAncor).
In this work, we challenge the latter assumption. We discuss the ways to prevent a transaction from being mined over substantial time (say, 100 blocks), which could be motivated by at least two scenarios:
- Attacking time-sensitive protocols (e.g., Lightning)
- Political sanctioning of certain payments
We discuss withholding any transactions rather than just two-party HTLC-based protocols, and assume the attacker does not participate in constructing the target transaction.
We focus on the “idealistic” Bitcoin protocol, instead of attacking Bitcoin transport or exploiting mempool behavior.
First, we go over trivial known ways to withholding a transaction, and then propose a smart contract overcoming the issues of the trivial approaches (namely, high cost and coordination).
I’m grateful to Antoine Riard for contributions to this article; Eric Sirion, Ruben Somsen and LLFOURN for review.
1.1 Vocabulary
- target transaction: a transaction to be withheld
- target tx fee: a fee, which a victim pays for the target transaction inclusion
- attacker: an actor willing to withhold the target transaction
- victim: a spender of the target transaction
- reward transaction: a transaction paying out a reward to the miner which withheld a target transaction
2 Background
Temporary Censorship Attacks in the Presence of Rational Miners discusses the game theory and miner rationality assuming different withholding strategies (SimpleBribery, CompensationBribery, FeatherForkBribery). Our work, in contrast, omits serious game-theory analysis, but rather focuses on designing withholding contracts for Bitcoin w.r.t. the capabilities of Bitcoin Script. My work also omits forking the blockchain. Our mechanisms could be used to implement something similar to CompensationBribery in Bitcoin.
MAD-HTLC : Because HTLC is Crazy-Cheap to Attack shows how HTLC in two-party protocols is susceptible to incentive-compatible withholding bribery, resulting in the loss of funds. This bribery is achieved with a trivial smart contract, paying out from the funds which would be lost by the counterparty otherwise. They propose to solve this with an alternative HTLC construction: MAD-HTLC.
He-HTLC: Revisiting Incentives in HTLC work claims that MAD-HTLC is also susceptible to bribery, if facilitated with TEE or ZKP. The He-HTLC construction improvement is suggested.
Both of these papers tackle issues with the construction of specific protocols, while we generalize to any transactions. Both MAD-HTLC and He-HTLC could be seen as a solution to the general withholdment smart contracts problem, although this is out of the scope of this article.
Smart Contracts for Bribing Miners shows how Ethereum’s proof-of-work mechanism could facilitate withholdment smart contracts. This method does not work for Bitcoin.
Feather-forking discusses the miners’ incentives to censor a transaction by forking the blockchain. It does not use the smart contracts for the payouts, because a miner and an attacker are the same entity. We attempt to separate the actors with smart contracts for implementing a similar attack. Smart contracts for forking were also suggested to implement via DLC, although without censorship.
CAT and Schnorr Tricks II mentions how exchanges could force withholding on the users by requiring them to enter a multisig with them (and how this could be enhanced with covenants). In my work, we assume that an attacker does not participate in transaction construction.
3 Mempool spam
The only in-protocol way to censor a transaction is to prevent it from being mined at the mempool level, by forcing the target transaction out of the short-list entering the next block. In the context of Lightning channels, this is known as flood-and-loot.
This method leaves a risk for the attacker because miners don’t have to adhere to the fee rate transaction sorting (either accidentally or with out-of-band payments). Additionally, an attacker faces the following challenges with setting the target fee rate:
- it’s unclear when to spam the network because blocks are mined at random intervals;
- sometimes blocks arrive immediately after each other, in that case, an attacker would want to fill the mempool for several blocks in advance to increase the odds, which increases the attack cost as well;
- assuming the target protocol is well-designed, a victim could bump their fees at random times (although an attacker could adapt, especially if bumping software is open-source), which could result in the scorched earth situation;
The cost of censoring one transaction for one block depends on the target transaction fee (and the victim’s ability to bump) and its position in mempools (and mempool activity).
For example, if the fee is 200 sats, and target transaction is at #2,000 position in the mempool, it would take 2,000 * 200 = 400k sats to keep the target transaction out of the following block.
In the cheapest case, if a victim targets the last position, the attack cost would equal the victim’s fee. A less efficient victim makes the attack cost higher: if the target position is second-last, the attacker will have to pay for expelling two transactions.
While this method is not bad in terms of guarantees and communication with miners, it is very expensive. Now we will attempt to minimize the attack costs, as well as improve the guarantees.
4 Approaching miners directly
Alternatively, an attacker could, contact all miners directly and offer a bribe. This would solve the challenges with block construction: if miners explicitly agree to the bribe, they would make sure no accidental block takes the transaction. Additionally, this makes real-time fee-bumping harder for the victim, leaving them oblivious to the withholdment contract details.
This would also assure the lowest attack cost. While it’s unknown how much fee overpayment is sufficient to persuade a miner to perform this, in theory it could be as little as 1 satoshi on top of the target transaction fee (just to increase the immediate gains of a given miner).
The main challenge with this approach is the impossibility of coordinating with all miners:
- some of them are anonymous and can’t be contacted
- it is unclear how to pay them in a trust-minimized way (without bonding, one of the parties has to trust another)
5 Using another chain
Arguably, smart contracts on an alternative chain (e.g., Ethereum) are probably sophisticated enough to implement TxWithhold Smart Contracts in a straightforward way: they indeed could work on Ethereum against Ethereum, and probably could be easily applied to Bitcoin via an Ethereum smart contract tracking Bitcoin SPV state.
It remains an open question whether these chains could be a good coordination layer for withholdment. Additionally, the model gets much more sophisticated with additional concerns of those chains, e.g. MEV.
6 TxWithhold smart contracts
We will attempt to combine the best properties of the approaches presented above:
- minimum trust involved: miners are guaranteed to receive the reward by a UTXO (and, possibly, an external oracle)
- to claim the reward, miners are required to “skip” only the target transaction, which is the minimal possible effort, and thus requires minimal attack cost
Communication with miners is reduced to public announcements from the attacker (a bulletin board system) for publishing the target tx (or UTXO), the reward UTXO, and other details of the deal (e.g., withholdment duration) required to unlock the reward UTXO.
TxWithhold contracts should pay the reward back to the attacker if the target transaction was mined.
TxWithhold contract design involves two components: proving the transaction was mined (or not mined) and claiming the reward.
The system we suggest should work on Bitcoin today, although we briefly discuss which changes to Bitcoin could enable better TxWithhold Smart Contracts.
6.1 Block validation level (does not work)
The rules enforcing a withholdment contract could live at the block validation level, for example: by making a block invalid if both the target transaction and the reward claiming transactions are spent.
Since Bitcoin Script does not allow inspecting the UTXO set at transaction validation time, this is impossible today.
However, a poor protocol design in case of the multi-input transactions could enable this by allowing the attacker to attach inputs to a target transaction. Designers of sophisticated protocols should consider this risk.
Now, let’s try to accomplish the goal by splitting the problem in two parts: proof-of-mining and reward claiming.
6.2 Proof-of-(not-)mining
We found two ways a smart contract could “check” whether a target transaction was not mined (or whether a target UTXO was not spent), and unlock the reward if the condition was met.
6.2.1 Transaction not-inclusion oracle (DLC)
An attacker could ask a set of trusted oracles to look after a target transaction (or UTXO), and issue signatures claiming that at time T (or at block X) the transaction still has not been mined.
These oracle attestations are likely to emerge in practice even without strong demand for withholdment, but just facilitating honest use-cases instead (e.g., on-chain lottery).
An attacker then publicly announces the set of oracles it uses and the conditions and creates a UTXO which this oracle could unlock.
6.2.2 HTLC or Schnorr magic (does not work)
If the target transaction is locked under a hash, a preimage revealed to spend it could replace the oracle signature. Alternatively, a signature required to spend a target transaction could be used (although we don’t have an exact construction in mind).
This doesn’t work because it would make the reward transaction spendable once the target transaction is revealed (enters the peer-to-peer network), not once it’s mined.
In other words, since the transaction doesn’t go through any changes from being published to being mined, it is impossible to rely on this method.
This idea, however, could be useful to optimize rewards, which is discussed later.
6.3 Reward allocation
The goal of withholdment contracts is to convince the miners that they will get the reward. The challenging part is linking the reward to the exact miner who performed withholdment.
Obviously, Bitcoin Script is not expressive enough to clearly state that “every miner which withholds a transaction will get the reward”. Reversing the problem to “anyone (proved to withhold) can take the funds unless an attacker presents the proof of inclusion and claims the funds earlier” does not allow it either.
Thus, we overview potential non-trivial solutions to implement this on Bitcoin Script today.
The mechanisms we present require an attacker to create (at least) one reward UXO per a block of withholdment and to provide some additional data (e.g., conditional pre-signed transactions).
6.3.1 Pooling withholders
A solution to giving out the reward could be amortizing it across many miners. Assuming the attack is long enough (say, 100 blocks), an attacker could create the following reward UTXO: if the oracle confirmed the withholdment in the last block, miners could claim the reward by spending the UTXO with a pre-signed transaction proportionally to their historical hashrate distribution (and a small percent to *any* key, encouraging anonymous miners to participate too)
In this case, all the miners (including anon ones) are interested in keeping the withholdment rewards to be claimable.
An attacker has to confirm the UTXO conditional on the oracle signature and publish a pre-signed transaction distributing the reward. An attacker would do this for every block of withholdment in advance.
It remains an open question whether random anonymous miners would be happy with this reward, which they are not guaranteed to receive even if they’ve done the job.
6.3.2 One DLC/TX per miner
An attacker could create N (say, N=10) UTXOs, each committing to the public keys of particular miners, enforcing the given rules:
- in block X, a miner mines a dedicated transaction
- in block X+1, an attacker takes the funds back if the oracle proves transaction inclusion
- otherwise, the miner takes the funds in block X+1
Alternatively, this could be achieved by generating one DLC per miner, answering “Did miner XYZ mine the last block?”, in addition to the withholdment DLC.
These approaches can’t account for random anonymous miners claiming the reward and require one UTXO per every known mining identity. We believe this could be solved by the following approaches:
- a covenant which ensures that the positive branch could be claimed only by the miner of the first-stage transaction (e.g., by looking at the additional input attached by the miner);
- a covenant which ensures that in block X+1, only the miner of block X could take the funds
Both covenants could be replaced with a DLC, although we are not sure if a DLC could be binded to a spontaneous (unknown in advance) public key.
7 Discussion
Fee bumping
A withholdment victim is likely to bump their fee after observing withholdment (although this is not trivial currently), and TxWithhold Smart Contracts should accommodate reward bumping. The most straightforward way is to confirm another reward UTXO, although this increases the attack cost by the transaction fee paid to mine it, putting the attacker in a weaker position.
This issue could be solved with something like a unidirectional payment channel, although this would require an attacker to allocate excessive funds upfront (meaning opportunity cost).
Conflict of interest w.r.t. payout time
There is the following conflict of interest in practice:
- an attacker is usually interested in all-or-nothing withholdment: an attack should either last N blocks or not last at all (thus, paying for M<N blocks of withholdment is less preferable)
- each miner prefers to get paid block-by-block, to reduce reliance on the behavior of other miners (which could include the block later)
Contract parties would have a better chance of agreeing to the deal if it was more flexible: e.g., a miner gets paid part at the withholdment time, and part once the attack is over.
Seemingly, this would require the sophistication of smart contract construction, so we leave this exploration for future work.
Exclude odd payouts
An additional oracle guarding that the target transaction was published, or the HTLC/Schnorr trick could ensure that the transaction was submitted, and was withheld (as opposed to not being submitted by the victim in the first place).
It is often unknown in advance when the withholdment period starts: e.g., the target transaction could be safely delayed by the victim.
This could be achieved by linking the reward to the preimage (or a signature) of a target transaction so that the attacker does not overpay.
TxWithhold off-chain
Assuming miners run known Lightning nodes, an attacker could contact them directly instead of publishing contract details on a bulletin board.
An attacker, in this case, could even move the smart contracts to the lightning level by slightly updating the HTLC construction.
While this reduces the burden of bulletin board infrastructure, a new assumption of all miners running a public Lightning node arises. Additionally, it leaves no chance for reaching out to the anonymous/small miners, which could look at the bulletin board otherwise.
If this solution uses DLCs, it would also require one-DLC-per-miner, because the channel-related contracts should be isolated.
Forking undesirable transactions
If a transaction did make it into a block, an attacker could attempt to bribe miners into ignoring this block, and building an alternative fork on the previous block (this is known as feather forking).
We believe that building a smart contract encouraging feather forking w.r.t a target transaction is equivalent to building a TxWithhold Smart Contract, so all the discussed challenges, arguments, and methods remain valid.
8 Conclusions
Understanding practical aspects of withholding Bitcoin transactions helps to better understand the properties of Bitcoin in general and the security of certain protocols/use-cases in particular.
In this work, we explore constructions enabling TxWithhold Smart Contracts, aimed to make bribing miners for excluding transactions from blocks more practical.
While these smart contracts could be deployed today and achieve some goals, in practice their guarantees towards miners are far from perfect, especially w.r.t small anonymous miners.
Additionally, the usability and cost efficiency (w.r.t. an attacker) leaves us with some unsolved challenges. Some of these challenges could be “solved” with covenants.
Related
The post appeared first on Blog BitMex
