RFC: Minimum-bid PoX (to thwart Bitcoin MEV)

I’m not sure I agree with this. MEV is possible because miners are able to deduce the true value of a transaction before the transaction is mined (or sufficiently confirmed), and take actions to extract that value at a profit. If they are able to do this, then of course they will try and capture extra value from the transaction – if they don’t, then other miners will, and out-compete them.

This suggest that the defining characteristic of a MEV-free protocol is its ability to ensure that any value-extraction strategy would never be profitable. We don’t have to share MEV among miners; we just need to ensure that any MEV strategy they could take can never make them more money than honest participation. I think that this is achievable in general with careful protocol design, and can be done specifically with Stacks mining.

Recall that Bitcoin miners rely on two means of extracting value. They can:

  • Decide the order in which transactions are mined in their blocks
  • Decide which transactions get included in their blocks

Today, Bitcoin MEV miners extract value from Stacks mining by ensuring that only their block-commit transactions get mined in the Bitcoin blocks they produce. Then, they’re guaranteed to win the Stacks block reward for a minimal cost to themselves (namely, the cost of a forfeited Bitcoin transaction fee).

What would a MEV-free mining protocol look like? A MEV-free mining protocol would need to prevent Bitcoin miners from underpaying for STX by means of delaying or reordering Stacks miners’ Bitcoin transactions. I think this could be achieved by lifting all Stacks mining to an open-membership mining pool, and rendering that the de-facto mining mode. Beyond that linked post, I think we would specifically require the following behaviors:

  • Stacks transaction activity happens mainly within microblocks, not blocks. Microblocks are signed by a majority threshold of miners (e.g. 66% or more by BTC weight) before they confirm, and this all happens off of the Bitcoin chain. Microblock stream budgets grow dynamically as a function of provable time delays (via a VDF), so the chain nominally remains live regardless of what happens with Bitcoin blocks.

  • Every so often, Stacks miners collectively send a “checkpoint” transaction on Bitcoin. This checkpoint commits to the current tip hash of the microblock stream, and consumes any UTXOs sent by Stacks miners wishing to join the pool. It also re-seeds the VRF and resets the block budget VDF, and pays PoX recipients. Checkpoint transactions are targeted to every Bitcoin block, even though some of them may not get mined right away (e.g. due to flash blocks or attempted MEV behavior). Checkpoint transactions replace sortitions.

  • PoX payouts are a function of the aggregate BTC held by the pool, and cannot be chosen by miners. If a miner commits X BTC to the pool, then in checkpoint transactions S through S+N, the PoX payouts increase by X/N BTC. A checkpoint transaction is not valid unless this is true. The miner receives a pro-rata share of the block’s STX as a function of what percentage of the BTC they were responsible for committing in each checkpoint S through S+N. Neither Stacks miners nor Bitcoin miners can change the rate of PoX emissions – they can only slow down checkpoints. Below, we’ll make the act of slowing them down unprofitable.

  • Checkpoints trigger STX disbursement to the miners and PoX payouts to Stackers. Reward cycles are measured in the number of checkpoint transactions successfully mined, not the number of Bitcoin blocks. The only way for miners, including Bitcoin MEV miners, to get STX and PoX payouts is to ensure that checkpoint transactions are mined in a timely manner.

  • There will be a well-defined protocol for would-be miners to join the pool by sending BTC. Would-be miners create a “pool-join” UTXO, and the Stacks mining pool spends the UTXO to add the miner. These pool-join transactions are sent to both the Stacks chain and to the Bitcoin chain, and Stacks nodes verify that these pool-join transactions are mineable on Bitcoin. By doing this, the consensus rules can require nodes monitor the Bitcoin chain for MEV behavior: if the mineable pool-join UTXO is not spent within a fixed number of Bitcoin blocks (something that Stacks nodes can collectively track), then STX and PoX disbursements are delayed until it is consumed. This means that Bitcoin MEV miners block STX and PoX payment to themselves by preventing other non-Bitcoin-MEV miners from joining.

If we can do all of these things, then the only profitable course of action for a MEV miner would be to participate honestly. Refusing to mine checkpoint transactions or pool-join transactions merely delays disbursement of any STX or PoX rewards they might be entitled to. Moreover, there’s no money to be made by 100% blocking these checkpoints and pool-joins, because then Bitcoin miners wouldn’t get any STX or PoX payouts.

Aside: I don’t think block pre-commits solve this problem (see my L1 improvements post), because if enough Bitcoin miners wanted, they could prevent any block-commit besides their own from getting enough pre-commitments. Importantly, they can do so without spending extra BTC, meaning that they’d be getting the STX at lower cost than honest mining. Block pre-commits solve a different problem: among other things, they ensure that Stacks miners get some STX for trying to mine on the canonical chain tip (even of other Stacks miners orphan it later). If Bitcoin miners are in on the Stacks mining game, then Bitcoin miners with minimal Stacks mining power can still prevent Stacks miners from pre-committing.

2 Likes