## Intro

Most of it feels like implicit knowledge, but I couldn't find anything written 
so here it is. The ideas towards anchor outputs and the conclusions probably 
have some new perspectives.

This post is about the game-theoretic security of time-sensitive protocols if 
miners are open to censorship for a reward. To become practical, the following 
has to happen.

1) a substantial hashrate has to be willing to participate in this behaviour, 
according to the known formula from the Whitepaper. The more blocks it takes to 
attack (defined by a particular protocol configuration and could be tuned), the 
exponentially higher % hashrate is required.

2) a communication layer is required to send bribes to these miners. This could 
be a private transaction relay network, or a mempool allowing still-time-locked 
transactions. It could be even an announcement board (e.g., submitting raw txs 
under a Twitter hashtag and inviting miners to monitor it).

3) a bribe transaction construction (will be explained later).

In this post, I talk about the case when:
1. a significant hashrate (e.g., 95%+) is open to take these bribes;
2. but miners don't trust each other;
3. and there is no reorgs.

Assumption \*(2) is more nuanced. What I mean here is roughly "miner X would 
rather take an immediate gain than commit to a lenghty scenario where many 
miners coordinate to take reward on behalf of each other and then distribute it 
accordingly to the hashrate". The game theory of this assumption should be 
better defined in the future.

We will see, how widely known tweaks lift the bar for (2) and (3) and how this 
could be further improved.

*A special case of this scenario is miners withholding Alice's transaction to 
force her to bump fees, even if Bob hasn't submitted a bribe. Here I assume 
miners won't do it unless there is an external incentive (Bob's bribe), 
although this issue is also interesting.*

## Simple opcode-based construction

The simplest time-sensitive two-party contract is PowSwap (a bet on the future 
block issuance rate), a single on-chain UTXO with the following spending 
- Alice’s key can spend if height=H is reached;
- Bob’s key can spend if Time=T is reached.

Say H is approaching quickly, and T is far behind. Bob now uses a private 
mining relay to submit his non-mineable transaction paying e.g. half of the 
UTXO value towards fees.

Alice has two problems: 1) she can’t figure out why her transaction isn’t mined 
and how much fee to overpay; 2) the attack is free for Bob (he has nothing to 
lose), while Alice loses everything up to the full UTXO value.

## Simple nLockTime-based construction

If parties use pre-signed transactions with nLockTime (instead of the opcodes), 
Bob’s fee can be pre-signed to a rather low value, so that Alice can reasonably 
overbid it without much loss (she probably doesn't even need to take any 

Bob can, however, bump the fee by creating a CPFP transaction with super-high 
fee. All it requires now is submitting twice as much data to the private mining 
relay (and burning slightly more in fees).

## nLockTime-based construction with OP_CSV output

If Bob’s output can’t be spent right away, but is forced to be deterred to even 
one block in the future, it makes taking this bribe not rational: a censoring 
miner can’t be sure about the deferred reward (remember, miners don't trust 
each other). At the same time, mining the honest transaction and taking its fee 
is always available earlier.

Smart contracts could possibly make it rational for miners (see [1]), e.g. by 
allowing Bob to allocate the bribe based on the historic hashrate distribution 
linked to coinbase pubkeys.

At the same time, this approach makes dynamic fee management impossible.

## Anchor outputs

Anchor outputs allow bringing external capital for fee management while locking 
internal capital. Bob can use this capital for a bribe. If the attack fails, 
Bob's external capital remains safe, so this is not so bad for Bob.

The attack can be more costly if this external capital was claimable:
- by Alice: e.g., Alice can steal a (covenanted) anchor output if it's revealed 
before Bob's nLockTime makes it mineable (requires her to monitor the private 
- or by miners, e.g. if Alice forces Bob, at contract setup, to use a reverse 
time-lock (the anchor can be stolen by miner if seen before time=T); or if 
mining Alice's honest transaction also allows miners to take Bob's fee output 
(e.g., Alice's honest transaction *could* act as a parent/preimage, 
conditionally, although this may require reverse time-locking Alice to protect 

*Ephemeral anchors doesn’t do much w.r.t. our trade-off, as it is a 
mempool-oriented thing.*

## Lightning

Lightning is different from the described protocol in two things:
1) It relies on intermediate transactions (e.g., Commitment in Poon-Dryja);
2) Usually both parties have some balance in the channel.

I believe that (1) doesn’t change the situation much, it just makes it more 
(2) is irrelevant because an attacker can just spend the entire channel before 
the attack.
Thus, most of these concerns apply to lightning equally.

## Related work

The LN paper briefly mentioned this problem, although it was claimed 
impractical due to a high degree of required collusion. We already see private 
mining relay in mevwatch.info (ethereum), and we had FIBRE (I think it was 

[2] discussed constructions and economics for bribing miners. [1] suggests more 
practical considerations for achieving this. Both don’t focus on the risks of 
particular time-sensitive protocol constructions.

[3] highlighted a similar protocol risk, but the proposed solution seems to 
work only if an attacker has funds to lose locked in the contract (e.g., 
collateral, lightning balance, powswap payout).

## Conclusions

To increase the attack bar w.r.t the configuration described in the intro, we 
should either:
- stick to the *nLockTime-based construction with OP_CSV output*, forget about 
dynamic fee management, and hope that bribe allocation smart contracts doesn't 
work out;
- use anchor outputs (or another external fee scheme), but enforce a way to 
steal/burn the external fee if it's an attack;
- design new fee/channel constructions.

These ideas may also be helpful for alternative payment channels designs as 
well (v3+ephemeral anchors, SIGHASH_GROUP, etc.), or in the future to protect 
against more powerful covenants allowing stronger bribes (see [1]).

Thanks to Antoine Riard and Greg Sanders for initial discussion.


## References

1. TxWithhold Smart Contracts by Gleb Naumenko | BitMEX Blog 
2. Temporary Censorship Attacks in the Presence of Rational Miners 
3. MAD-HTLC: Because HTLC is Crazy-Cheap to Attack 
bitcoin-dev mailing list

Reply via email to