Orphan MEV


This would be a quick and elegant first step in the right direction.

If there are no block rewards for any sibling blocks, it would be much more expensive for a bad entity to push out smaller miners. This small adjustment could drastically reduce the number of orphaned blocks.


And the best part, it should be pretty easy to implement and could get integrated with the second hardfork in 23 days (pox-3 fix)?

1 Like

Sharing the already public draft for visibility
MEV_Report_Draft_v2.pdf (1.6 MB)

Basically, you’re up against FLP impossibility. A node cannot determine whether or not a block it doesn’t have exists. The worst-case scenario is that some nodes have the block, but others do not, and these two sets of nodes create a chain split due to the conflicting block reward allotments that would result.

Now, it might be sufficient to just not care about whether or not the Stacks block exists. The node might instead only look at block-commits, and withhold the block reward for a block if there exists any sibling block-commit that won sortition (even if there is no corresponding block). The downside to this approach is that someone could “snipe” honest miners by deliberately sending winning block-commit transactions – a problem that doesn’t materialize if the node additionally considers Stacks blocks. But if we can convince ourselves that “sniping” is unlikely to happen over long periods of time (and I suspect it will not – it’s not a money-making action), then we could get away with only considering the existence of sibling block-commits when withholding block rewards. This would be a lot easier to pull off, and could be done in a hard fork before sBTC.

1 Like

This could also help for Bitcoin MEV miners (see block 2’’ and 2). 2’’ would not be part of the canonical chain.

How does it work in the current situation with miner collusion? Not sure I understood yet.
How are miner commits linked to blocks? In the diagram below I tried to assign the miner commits to blocks.

Is it possible to do a deeper fork across several blocks with commits higher than the sum of the forked blocks?


Editable diagram online

We can firm things up as follows:

Stacks miner making their btc commitment transactions must also include the stacks block height for which they are producing the block for. If this information is not already part of the existing protocol, then perhaps it can be as part of their bitcoin tx memo.

So suppose miner Alice is making btc commitments, she must then also include in the commitment what stacks block height she sees as the chain tip. If she wins sortition, the block she produces must be at the height she attested to. Otherwise it is an invalid block.

If all the miners are in sync, then the commitments for every stacks miner for a given btc block should all point the same stacks block height.

If it isn’t then we can conclude there is orphan behavior.

Because each commitment is labeled by its miner as to where they think the chain tip is, we can determine how much the orphan miner is paying to try to orphan a block. If the orphan miner wins the sortition and presents a block (S-1)’, the honest miner nodes must sum up the orphan miner’s commitments (his portion only, not the entire block’s commitments). If the amount committed is less than the block subjected to being orphaned, then the orphan miner’s forking block is not accepted. If it is greater, then we can make a case that it should be accepted.

Under these rules so long as honest miners’ economic contribution to the network is greater than 50%, the orphan miner will not be able to fork.

The current situation is that the honest miners do not have more than 50%

I tried to show the stacks chain tip and the commits in the updated diagram. Does that make more sense?

1 Like

Is it possible to fork like this?

Yes, in general it will be possible to fork any portion of the block history with enough money. This is true currently as well with the winning chain being the longest chain. Imagine the following: a bitcoin miner with superior secret technology that is 100x faster than all the competition can reorg the chain from a long way back. In the case of stacks, the “superior secret technology” is just cash.

The miner p2p chatter cannot be a source of truth. If we penalize “block orphaners”, we have to analyze the case for relative advantages if the subversive miner switches to be a “block withholder” thereby making honest miners apparent “block orphaners”.

Because miners can determine the chain-tip and the contents of the block, they will be able to fork and rewrite any part of the chain via a combination of money spent and choice-of-block tactics and the best we can do under these conditions to make rules that makes subversive forks more expensive money-wise, but a determined forker can still succeed.

This makes me to rethink the approach of:

  1. separating the chaintip decision-making to stackers. This is similar to SIP-021 with 1-block blessing. It is possible to design it such that a take-over of this mechanism would require the subversive actor to control a large percentage of the stacking marketcap (economically unfeasible).


  1. for miners to not be dependent on miner p2p chatter for relaying and receiving block information after winning sortition. Stackers can have their own p2p network and miners send their proposed blocks to stackers’ network for attestation/indexing then submit a hash of their blocks with their commitments. When a miner wins sortition, the rest of the network can query a quorum of stackers with the hash to dereference the block of the winning miner. As long as quorum of stackers can retrieve the block, every actor will see the same chaintip and no fork is created. It will be much more difficult to gamify a p2p network of stackers because the design space of countermeasures will be much larger I believe.

Both of these strategies limits the “choice-of-block” degree of freedom from miners.

*sorry for the insane amount of edits. I accidentally cleared the post and had to retype.

1 Like

Both approaches 1. and 2. require more involvement of stackers.

Is there a smaller solution, like not paying any rewards for orphaners? It is not perfect, but it penalizes orphaners and does not add more penalties to honest miners.

Let’s suppose miners that produce orphan blocks are not rewarded, then the MEV miner can still achieve a relative advantage against honest miners by switching from being an orphan-miner (a miner that publishes their winning blocks but refrains from receiving honest miner’s block to integrate into their view of the chain) to being a block-withholder (a miner that refrains from publishing their winning block to the rest of the miners until a later strategic time).

Imagine the following scenario:
Suppose the chaintip is at stacks block 1000 (stx1000) at bitcoin block 200 (btc200). Let’s also suppose all miners up to now are in consensus and there are no hidden forks. Next, the MEV miner wins sortition at btc201 and builds block stx1001 but withholds this block from the rest of the miners. Now the MEV miner sees the chaintip at stx1001 while the rest of the honest miners see the chaintip still at stx1000

Next, the miners participate at sortition btc202 and the MEV miner wins again and builds stx1002 on top of stx1001 but withholds this 2-block chain. Now the MEV miner sees the chaintip at stx1002 while the rest of the honest miners still see it at stx1000.

Next the miners participate at sortition btc203 and an honest miner wins and builds their version of stx1001 (let’s call it 'stx1001) on top of stx1000 and publishes this result.

At this moment the MEV miner also releases his 2-block fork to the rest of the network. How does the network interpret this event? Well the MEV miner has a longer fork and also verifiably older fork and the reason stands that maybe the p2p propagation was problematic or slow. The network would conclude that the honest miner’s 'stx1001 block is trying to orphan stx1001 and therefore the honest miner is the orphaner and is denied their block reward. The MEV miner claims his reward for the 2-block fork while the honest miner burned his commitment capital. This repeated over time could cause the honest miner to drop out which is in-effect the same as the original MEV orphan miner problem. Please correct me if I’m wrong.

If the “withholder” is penalized (as it currently is), then the MEV miner will act as an “orphaner” to make the rest of the network “apparent withholders”. If the “orphaner” is penalized then the MEV miner with act as a “withholder” to make the rest of the network “apparent orphaners”. The gist is that no assumptions nor conclusions be made by the p2p chatter between miners as to who “withheld” or “orphaned” a block.

What if both withholder and orphaner are penalized ?

A full stacks node syncing the history of the blockchain cannot distinguish using the blockchain data as to which actors “withheld or orphaned” a block. This is real-time behavior of the p2p network and is by nature subjective because no one has a privileged view of a network that is decentralized and trustless. The stacks node is only concerned with cryptographically verifiable data recorded in the Stx blocks and the btc blocks to validate the state of the blockchain. The data packets/message timing between the miners are neither information that is recorded nor objectively provable. The node cannot look into the past and replay the p2p network traffic history between miners to issue judgement.

But we could penalise the miner of two blocks. The one for for btc202 and btc203. The penalties would hit one honest miner and one orphaner, or one withhelding and one honest miner. It would not change the outcome of the honest miner. It would make it a bit more expensive for dishonest miners, wouldn’t it.

The 2-block chain is accepted as canonical. Why would it get penalized? If a fresh node is syncing from the genesis block, it would see two blocks that were missing rewards. If you said it was penalized its rewards because this miner was “withholding” then where is the irrefutable proof? You could never reach a consensus whether “withholding” actually took place. Miners that are allied to the MEV miner would not experience any “withholding” at all as they would propagate block within themselves and everything looks kosher. In fact they could claim the honest miner is trying to maliciously fork because the order of the blockchain data actually supports that view (honest miner’s block trying to reorg a block earlier in the chain) and they shouldn’t be denied of rewards because of other people’s action out of their control.

Currently, we see penalties for actions out of their control when blocks are orphaned.

The protocol should make malicious behaviour more expensive.

Would be the solution to pay miners of orphaned blocks as well? Then at least the protocol does not penalize miners for actions out of their control

I think this is the least disruptive way forward. Escrow the stx block reward and pay out pro-rata according to the block commitments made within a sliding window of btc blocks. This includes commitments that did not result in a block in the canonical chain. This way there is no relative advantage - with regards to capturing the block reward - by controlling the outcome of blocks on the canonical chain. Everyone will be paid on the level. Orphaning/withholding behavior might still continue if these mining entities deem it to be selfishly beneficial to control the transaction history/ordering on the blockchain outside of capturing the block reward. However with pro-rata payouts, we could see a willingness for new miners to enter, increasing the proportion of “honest” mining capital commitments thereby making exclusionary mining tactics more difficult to maintain.

Also since the BitcoinMEV proposals proposes something similar, 90% of the solution could already be baked in - we’d just have to make sure to include miners of orphaned blocks in the pro-rata payouts as well.