Have a look at BTC Block 781455-781456 (Link). Small miners like SP2P and SPN8 produced correct blocks in an event where the entity was offline. Without these miners 3 out of 5 BTC Blocks (781451-781456) would be empty.
And the controlling entity would win+3000STX on top without a single commit. => It supports centralization.
Pre-Commits like proposed in “RFC: L1 Speed Improvements” could solve this isssue?
Another possible mechanism could use reward weighting. Mining rewards mature after a period of time, and in a weighting scheme, the rewards do not necessarily go directly to the block winner. Instead, the protocol looks at a window of block winners, and splits the reward over that window according to the proportion of funds committed during that bitcoin block.
For example,
Bitcoin block 1 → 3 miners participate, total committed funds are 1 BTC, block A is selected
Bitcoin block 2 → 3 miners participate, total committed funds are 1 BTC, block B is selected
Bitcoin block 3 → 1 miners participate, total committed funds are 0.001 BTC, block C is selected
Bitcoin block 4 → 3 miners participate, total committed funds are 1 BTC, block D is selected
Bitcoin block 5 → 3 miners participate, total committed funds are 1 BTC, block E is selected
Bitcoin block 6 → 3 miners participate, total committed funds are 1 BTC, block F is selected
Bitcoin block 7 → 3 miners participate, total committed funds are 1 BTC, block G is selected
Say the “reward window” is size 5. When Block A’s reward matures, its coinbase reward (let’s use 4 STX as the reward to simplify things) is split amongst the miners of A, B, C, D, E – weighted by the amount of funds committed in their bitcoin blocks. So miners of A, B, D, E get ~1 STX, and the miner of block C gets ~0 STX. When Block B’s reward matures, miners of B, D, E, F get ~1 STX, and the miner of block C gets ~0 STX. When Block C’s reward matures, miners of D, E, F, G get ~1 STX, and the miner of block C gets ~0 STX.
Obviously, this proposal would alter the incentive structure of the protocol (almost any change to the protocol does) and would require further investigation, but it would eliminate the coinbase incentive for MEV.
Another possible mechanism could use reward weighting . Mining rewards mature after a period of time, and in a weighting scheme, the rewards do not necessarily go directly to the block winner. Instead, the protocol looks at a window of block winners, and splits the reward over that window according to the proportion of funds committed during that bitcoin block.
This is interesting and seems more incentive aligned.
Ultimately, I think this is a good thing to happen now and discuss solutions before sBTC goes live. It’s also validating to see major BTC miners participating in STX!
Now that 2.1 is live we should have mining pools live soon so it would good to put extra attention on the efforts the Stacks Degens team is making with that. I can see the launch of these mining pools raising mining participation by at least 100x.
Hey everyone! Thanks for all the comments and suggestions here. @jude and I discussed this issue some weeks ago and in general, we’ve known about this potential MEV vector for a long long time. For example, I even responded to comments by @bergealex4 on Twitter about Bitcoin miners potentially doing this.
We’ve floated the idea of a minimum bid as a clear way to stop MEV from Bitcoin miners. It basically means that Bitcoin miners will have to bid at least a minimum amount of BTC to get the STX rewards (if they don’t bid at least the minimum amount then they get 0 STX even if they try to censor other miners).
The solution Jude proposed above is in-line with this thinking. Jude is debating what would be a good way to calculate the minimum bid. I think aiming for 90th percentile of the bids in the last 1,050 blocks (so approx one week) is one way to do it.
Also, it’s great that Stacks layer is becoming so successful that even Bitcoin miners are looking for MEV. This was only a theoretically thing earlier and now we have some evidence. We could’ve implemented the minimum bid earlier but thought the issue was very theoretical at that time and didn’t prioritize it enough. It can be prioritized now.
In terms of the actual implementation and roll out. I don’t think there is any need to rush the update. This mining pool has been doing this for weeks already. There is no direct impact on the protocol correctness. It’s a question of potentially reduced BTC rewards to stackers but the absolute reward rate is significantly up already from a few months ago. I’d personally treat this as any other upgrade that improves the network. Test it throughly. Also, consider if there are any other small tweaks after the 2.1 launch (like the mempool issue that Aaron discovered recently) that can also be packaged into the same release and then follow the standard upgrade process to put a new binary out.
If a new binary can be out within weeks that’d be amazing!
If this was not already implied: A possible approach could be to use the stacks miner Btc pre-commitments described from the rfc L1-speed increase (when live) to judge the difference between the aggregate amount of Btc that was precommited vs actual to determine whether to grant the Coinbase reward.
Agree with Muneeb, I don’t think there’s any rush on this. It’s doesn’t break Stacks and stacking rewards are way up in $$ terms regardless. It was expected this would happen at some point. Many may not agree but I wouldn’t even be worried if all miners started doing this now and PoX rewards went to zero in the short term. It doesn’t even break sBTC fundamentally. While Stacking has Product/Market Fit there will be many other Product/Market Fits from apps built on top of it. It’s validating miners are taking note of STX and there’s several viable ideas on how to counter this we can explore to figure this out and implement before sBTC goes live.
I believe stacking yield is one of the most compelling use cases for hodling STX. I fear concentrating too much on the decentralization of mining and/or taking more time to implement a hard fork to correct this issue will be to the detriment of stackers earning their associated yields. I know continuing the network as it currently is doesn’t break the network at the moment but Stackers and the TVL they provide should not be put on the back burner. There are far more stackers than miners yet both are equally as important to the successful operation of the network imo. I’m part of the keep yields high camp as I ultimately believe this is what will also attract the most users to Stacks. We start accepting the fact of lower yields now, regardless of its USD value, stackers will have a hard time getting that value back 
…
I don’t think anyone is arguing that the update should not go live soon. Technically the change is not very complicated so it can be tested relatively quickly. My comment is more like that instead of doing something within days and rushing, it is OK to take a few weeks and not rush this out. I do not think a few weeks make any meaningful difference if the tradeoff is that developers can do more testing and follow the standard procedure for pushing new upgrades. It will not take months or years to push this live 
We appreciate this proposal and look forward for an implementation. Anyway, we strongly believe that it must go hand in hand with the proposal: “Improve Throughput by Disincentivizing Missed Sortitions”.
Otherwise Stacks won’t get decentralized again - upcoming decentralized mining pools will suffer big losses (like other independent and smaller miners at the moment) and won´t be able to compete.
I like @aaron’s idea with the weighted block rewards. The nice thing with that solution is that the honest miners get to reap the rewards of the miner that censored them, further encouraging honest mining.
The other piece of information that we have that could be useful is miner history. If miner A participates in block N, there is a high probability that they participate in block N+1. This information could be factored into some scoring mechanism, i.e. each miner that participated in block N-1 but did not participate in block N increases the probability that the winner of block N was censoring miner transactions and should be punished. This information could help to target censoring miners, while still allowing honest miners with small commit amounts to sometimes get lucky and win the full block rewards.
This is fascinating. But how do you know it is one entity and not the result of some systemic failure (bug or misconfiguration)? For example, it looks like your node is missing information on lots of blocks that did have PoX bids (e.g. 781165), so perhaps there is some programmatic issue leading to these forks?
I had noticed that the MEV miner’s blocks are almost always forked away except by a couple of other miners. But I was inclined in the other direction to think that maybe those miners are cooperating somehow.
Either way I agree that these forks and missed sortitions are highly problematic and the pre-commits idea seems like a good direction.
I’d like to just take a step back here. Is this actually a problem that needs solving? Perhaps this hinting to us the direction of the evolution of Stacks. PoX is a great bootstrapping mechanism, but does it need to persist indefinitely, especially since there is now a new use case for Stacking (controlling the sBTC peg wallet)?
As @jude mentions, this is actually a good development as it means that Stacks is providing real value—enough so to get BTC miners considering it when mining. So while Stacking for PoX yield does indeed have a product market fit, it’s no longer the only reason to Stack as we’ll soon have sBTC.
Stacking plays a central role in sBTC by serving as the ongoing reward to sBTC wallet signers for being available to process sBTC unwrapping without charging the user a basis point fee.
If I understand correctly, there are no fees incurred when unwrapping sBTC? If so, I’d like to challenge that design assumption. If we allow fees for unwrapping then we now longer need PoX to incentivize Stacking as Stackers can now generate fees from unwrapping. Also, allowing a fee market to develop for unwrapping sBTC, can help address the sBTC collateral problem that has been discussed recently. If those that are unwrapping can specify a fee for priority in unwrapping, then it could give potential sBTC users more comfort in knowing that they can get out of sBTC quickly if the collateralization ratio falls too low for their risk tolerance.
If [merge mining is] 100%, then this tactic is unworkable
Agree with this. Once Stacks is 100% merged mined by BTC miners then the proposed solution will no longer work as all miners will just have their own dust bid included in BTC blocks so no amount of looking back at previous blocks will work. Since being 100% merged mined is a desired outcome, as that means Stacks is backed by all of BTC hashpower, then it makes any solution we have to this “problem” moot in the future. Our saving grace for Stackers is that by then we’ll have sBTC, so if we have fee market for sBTC processing then Stacking can transition from getting its yield from PoX to getting its yield from sBTC processing.
It is not a desired outcome. People want PoX to pay a yield, and with sBTC, that needs to be the case.
If not desired, then at a minimum it is a possible outcome and perhaps inevitable (assuming Stacks is successful at providing value)
People want PoX to pay a yield, and with sBTC, that needs to be the case.
Does that need to be the case if Stackers can earn yield from fees for unwrapping sBTC?
There is no universe in which I support an sBTC design that charges basis points for unwrapping. The fact that we don’t need to do this while also remaining incentive-compatible is a competitive advantage that no other system can match to date.
There is no universe in which I support an sBTC design that charges basis points for unwrapping
What happens if and when Stacks is 100% merged mined? Doesn’t PoX yield effectively drop to 0? Under that assumption, will the Stacking mechanism no longer exist or is there another transition that needs to occur for Stackers to somehow earn yield?
If there is no other way, then perhaps sBTC unwrapping fees can be that yield to Stackers under the 100% merge mined scenario
There are several approaches to make PoX not go to zero. One straightforward (but not necessarily an optimal way) is to put a minimal price to produce a block tied to the market price of Stx.
That approach seems like a nonstarter as you’d either need an oracle (which introduces a lot more complexity and assumptions) or you’d have to be frequently coming to social consensus as to what that minimum price would be which seems inefficient and intractable.
Seems like there would be less moving parts and thus less assumptions required if we use sBTC as a yield generating mechanism for Stackers.
No, it means we lift the minimum-bid calculation off-chain. Stacks miners would send blinded transactions to Bitcoin to vote on what the minimum-bid should be, and send the unblinded value to the Stacks p2p network. Then, the Stacks node software will not accept a block unless its block-commit paid the minimum PoX output. Furthermore, we’d take steps to blind block-commits themselves so that Bitcoin miners can’t know in advance whether or not a transaction will be interpreted as a block-commit transaction before they mine it.
No, it means we lift the minimum-bid calculation off-chain.
Is this something you’ve written about previously? If so, could you share a link where I could learn more?
Stacks miners would send blinded transactions to Bitcoin to vote on what the minimum-bid should be
What’s the incentive for miners to vote for a minimum above 0?