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

SIP SIP: RFC
#62

That is correct, but the unit has always been in control of 80-100% of the mining power over the last months. The decentralized mining pool would have to invest roughly 4.5BTC per day to reach 50% (atm without the MEV miner) and still would not be able to compete against the entity (they would lose the bulk of the invested BTC). In theory, the problem could be solved if the honest miners had 90% of the mining power, but since this is uneconomical it remains a theory.
That’s why we wrote “doomed to fail”.

Right. “The reason why this doesn’t happen on Bitcoin (at least in theory) is because miners have a long term commitment with the Bitcoin network i.e. they purchased ASICs whose only way to monetize is mining Bitcoin for years. They are discouraged to damage the trust in the system that allows them to get a profit on their capital expenditure.
But Stacks is mainly operational expenditure, so miners don’t have such commitment. They don’t have an up-front cost that forces them to stay mining for long periods of time in order to get a profit.”
– JoseSK999

As Jude wrote - there are a few different ways we can encounter this problem which are outlined here and elsewhere. We want to highlight that its important to include it in the next hardfork, togehter or before we encounter MEV mining (otherwise they will be forced to stop due to the sybal attacks). Contrary to popular belief, the MEV miner would help decentralized mining pools to reach >50%? And both issues (Sybal attacks and MEV mining) are ciritical for sBTC anyway.

#63

Thanks everyone for the discussion here!

I’d suggest splitting this forum post into two different topics:

(1) The original topic of the post which is the Bitcoin MEV vector, where a minimum bid can be implemented to reduce/eliminate the Bitcoin miner MEV vector.

(2) The second topic around orphan blocks. This is MEV at the Stacks miners level (not Bitcoin miners level) and somewhat similar to selfish mining (where miners ignore other forks and orphan them) although the situation is different here. We can call it “block orphan MEV” or something like that i.e., miners can potentially make more money by orphaning blocks and ignoring other miners.

@jude and I have discussed both of these in the past and have proposals for potential solutions for both.

Both of these are important topics and I’m supportive of implementing solutions for both in Stacks 2.2. I also agree with @MattySTX that we should discuss more on a call and then write up two separate descriptions for the broader community. The forum posts can become a bit hard to follow – thanks!

6 Likes
#64

I fleshed out two of the proposals mentioned this forum thread in the following document: Proposals for Bitcoin MEV issue - Google Docs

Feel free to provide feedback on it here or on stacks-core-devs in Discord. As mentioned in the post above, we do have an external contractor reviewing these proposals (in addition to proposing tweaks).

3 Likes
#65

Inviting everyone to join SIP call with Matty on 14th Apr, he has lots of stats on mining very knowledgeable.

#66

F2pool has stopped mining STX in recent days FYI. Maybe b/c they saw this thread. Maybe b/c they were tired of being orphaned every block by The Entity. Maybe some other reason. But fwiw they are not mining right now.

In terms of these proposals, I am strongly not in favor of a minimum total commitment, for a couple of reasons. First, good-faith miners get hurt, as pointed out by @muthu.btc early in the thread. Specifically, they get hurt when they make it into a Bitcoin block that other miners didn’t make it into, whether due to flash blocks, Bitcoin network congestion (i.e. high fees), or yes Bitcoin MEV. Obviously the Bitcoin MEV case is pure value extraction, but I’d argue that the other two cases are a real service to the network. An STX miner is mining a block that otherwise wouldn’t have been mined and doing it in good faith, and the protocol should not simply take their money b/c other miners failed to get into the block.

However, that’s not even the biggest issue. The biggest issue is that the proposal exposes Stacks to catastrophic scenarios where the network simply comes to a halt. @jonkho alluded to one such scenario above, which is when the BTC/STX exchange rate rapidly shifts such that it becomes unprofitable for miners to mine even at the 90th percentile total commitment. Most miners are not going to willingly lose money, so if the mining pool is self-interested and is not asleep at the wheel, then mining will simply stop. At best someone (likely the foundation) will need to willingly mine at a loss in order to keep the network going.

A similar scenario could play out if a large STX miner leaves the pool or goes offline for any reason. That loss of that capital would surely drop the total commitment of the mining pool below the 90th percentile. Maybe the remaining miners would immediately make up the difference, but that is far from a guarantee. Those miners would need to be monitoring and actively responding to the commitments of other miners, and they would need to have significant capital readily on hand. If the former is not true, then the miner will simply get screwed as they continue to pay BTC (and mine Stacks blocks) without any opportunity to win STX rewards. If the former is true but the latter is not true, then the miner will simply stop mining for the time being, thus driving the total capital of the mining pool even further from the 90th percentile threshold.

In regards to the sliding window proposal, I like that one much better. It’s fair to good-faith miners, doesn’t expose the network to catastrophic scenarios (at least not that I can think of), and places less of a burden on miners when it comes to monitoring the actions of other miners.

Fwiw I’m also in the camp that doesn’t think the Bitcoin MEV issue is that serious, especially with F2pool having now gone offline and with a plan to Lift mining off of Bitcoin possibly on the medium-term roadmap. But if the decision is to definitely act on this and we’re choosing between these two proposals, I would strongly favor the sliding window approach.

1 Like
#67

Also, there were a few calls to break out the Orphan MEV discussion into a dedicated thread. I started such a thread here FYI.

#68

This is not true. Today, if there are B Bitcoin blocks in-between Stacks blocks S and S+1, then the winner of block S+1 receives B coinbase rewards. Eventually, and in short order, it will be profitable to mine even if the minimum commitment is high and the STX/BTC price drops.

EDIT: to qualify this, the accumulation of “missing” coinbase rewards only applies when there was no sortition in each of the B Bitcoin blocks. This means that coinbases only accumulate if no one is successfully mining.

1 Like
#69

You’re right, I hadn’t considered that.

But if I’m thinking about it correctly, it still seems that miners would only mine every other Bitcoin block (or every 3rd or 4th block or whatever the exchange rate dictated) until conditions normalized. And that still feels like a degenerate scenario to me.

1 Like
#70

Hi, providing an update here on the MEV issue.

Our tokenomics contractor has gotten back with an analysis of the issue, and the proposed solution.

I’ll be drafting a SIP with the proposed changes imminently, but for now you can read the report here.

#71