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

SIP SIP: RFC
#52

Still two things I don’t understand about the Sybil attack miner.

  1. How it can be fixed other than organically having more mining competition
  2. The detailed mechanics of how it’s actually reducing BTC yield to stackers

On point 1…

Isn’t the problem that the bad entity controls a sufficient amount of total mining power that even if other blocks get made, they can win a few blocks in a row and thus create a new longest chain?

If, for example, 4 new honest miners entered with the same size, such that Sybil attack miner had <20% of total mining power, wouldn’t that prevent this behavior by making it effectively impossible? Isn’t that exactly how this is meant to be prevented?

What, other than a lack of mining competition from the aggregate set of honest miners to begin with, is enabling the Sybil attacker to ignore previous blocks and create new longest chains?

On point 2…

Mechanically, how is the Sybil attacker lowering stacking yield?

Let’s say honest miner A wins STX block 100,000. They do so by sending native BTC to mine that block. In doing so, BTC yield has already been paid to the selected stacking addresses.

Now, the Sybil attack miner ignores miner A’s STX block of 100,000 (version A), and wins 2 vrfs in a row, which they use to build on block 99,999 and establish a new longest chain.

They overwrite/ignore honest miner A’s block, and propose Version B of block 100,000 and a new block 100,001. To do so, didn’t the Sybil miner also have to send BTC to stacking addresses?

Thus, I don’t see how this inherently reduces the BTC going to stacking addresses, except for if the Sybil miner can spend less than an average miner - but aren’t they only able to ignore previous blocks specifically because they’re spending more than other participants? Is the hypothesis that they are indirectly reducing stacking yield by stifling new mining competition and aggregate mining activity in general?

1 Like
#53

The problem here is that when the 4 new honest miners enter, their miner software is set up to naively trust all miners. Therefore it’s not sybil attack miner’s 20% against other miners’s 80%. Because all the honest miners will still confirm sybil attack miner’s blocks.

Because honest miners simply cannot mine and the dishonest miner has no incentive to increase their commit.

Look at this over a longer term. For example, miner A participated in 100 blocks, committing enough BTC for a 25% theoretical win rate. They would be in profit if they had a 25% actual win rate. However, due to their blocks being ignored by dishonest miner B continuously. Their actual win rate is only 5%. This means they cannot profitably mine over a period of time, and will eventually stop mining. When they do that, the total miner commit on the network drops.

At this point, dishonest miner B has no incentive to increase their commit. So the total miner commit on the network is now lower than it should be in a correctly functioning mining system. New miners will join at some point, however they will all run into the same problem and eventually stop mining.

You can go back and look at the mining data for the past few months. In a perfectly competitive scenario, the total BTC commit per block should be very close to the BTC STX exchange rate. But it is much lower than that, most of the time it’s 50%-70% of that.

1 Like
#54

A bit of background. The behavior referred to by @Metastack_BMC and @yukan is consistent with someone running a white-glove mining service on behalf of multiple individuals. The BTC that funds the miners come from separate accounts, and the STX outflows go to separate accounts. Moreover, the nodes run on public IP addresses, which makes their presence obvious (which makes me think it’s not deliberately malicious – it’s trivial to hide this, but this pool is not doing so). Also, myself and @jwiley have made contact with one of the individuals participating in the service, and can confirm that it is not one person.

The mining pool orphans blocks outside of the pool at a very wide range of frequencies. On some days, they confirm honest miners’ blocks nearly 100% of the time. On other days, it’s more like 40% of the time. There does not appear to be any consistency to the behavior, but I (or someone) should get a spreadsheet of all of the confirm vs. orphan rates to see if there’s any kind of pattern to confirm this.

If they are trying to be malicious, then the fact that it’s not consistent at orphaning blocks is surprising. Again, because the mining pool is not taking any steps to hide their behavior, it makes me suspect that this orphaning behavior could be due to an unforeseen bug in the block relay code. I’ve opened an issue to outline the steps we should take to investigate this further, and steps we can take to make block relay more reliable (which would help us rule out bugs in the networking stack, if indeed that is the root cause).

At a meta level, this thread seems to be discussing two unrelated topics:

  • Bitcoin MEV miners underpaying for STX
  • Some Stacks miners’ blocks get orphaned more often than others

These are both problems to be sure, and I think the post @pavitthrap outlined above is a sensible course of action to addressing the first problem (which poses a direct existential risk to sBTC). The latter problem needs further investigation. I’m not one to call it an “attack” without smoking-gun evidence, nor am I inclined to do so until we can rule out the possibility that this is actually due to a bug.

However, the intentions of this mining pool is irrelevant. The more immediate problem its presence reveals is that mining is not fair enough. The property Stacks should have is that if a miner spends X% of the BTC for mining on the canonical chain (even if they’re orphaned later), then they should receive X% of the STX. This is not the case today, and is not the case for most Nakamoto-consensus blockchains – if your block does not fall onto the canonical fork, then you get nothing. But because Stacks can keep track of all forks that ever arise, we can address this in a future hard fork. There are a few different ways we can do this that are outlined here and elsewhere (so I’ll not repeat them), but I think this is solvable and can be addressed in the near future once we know more.

2 Likes
#55

We should not conceal facts but openly discuss existing problems?

1.) We provided a forensic snapshot last November which proved, that one BTC account funded > 80% of the miners at the time. They simply tried to hide their tx-connections. Anyway BTC-Forensic is merciless.

2.) Not anymore (since we talked in public about it)

3.) The fact that they block 100% of the blocks from the f2pool miner confirms that it’s not due to an unforeseen bug.

Perfect and again thank you for your effort.

3 Likes
#56

Why is this problematic? If the honest miners build on the Sybil miner’s blocks, the Sybil miner still has to outpace all of them collectively in order to propose new longest chains right?

If there is a bug with block propagation, certainly that should be fixed, but isn’t the low honest miner participation what is causing this bug to be so problematic?

If there is no bug with block propagation, and a miner is intentionally ignoring blocks, again we come back to the fact that low miner participation is really what makes this a problem right? To my knowledge, you can’t force a miner to build on a recent block (except by them having such little share of mining power that they can’t create a longer alternative chain).

Are you saying that some form of a reputation system (so honest miners would not build on Sybil miner’s blocks) would help the problem? I agree it would help, but it seems like a second-order term.

@jude @Metastack_BMC also would love to hear your thoughts

1 Like
#57

I am also slightly confused how this attack works. Please correct my understanding:

If the sortition winner is an honest miner (miner A) who provably earns the right to publish the next block (N+1), how can a competing miner (miner B) exclude that block, and when given the chance, publish a longer chain that replaces the (N+1) block with their own version and that all other nodes in the network would accept? Miners are supposed to only be able to build on blocks that have been created by the miner (miner A) that won sortition? If not, and it only depended on fork length wouldn’t that defeat the purpose of the sortition? Wouldn’t the Stx chain state become invalid if there was a block in its history that was not provably produced by its sortition winner?

Or perhaps am I missing the scope of the problem.

1 Like
#58

I hope these two examples (attached .png) help to understand the problem. In both cases the honest miners won ~56% of the sortitions but the bad entity earned more STX. The honest miners lost several block rewards (all orphaned blocks).

A bad entity is able to ignore honest miners blocks as long as they desire (self build release). The honest miners will build their blocks simply on the longest chain (default release). Thats why they are doomed to lose.

We reported this “hostile” takeover last September on Immunefi - but the foundation did not see the problem and persisted in claiming that it´s not a bug or any kind of critical issue.
stacks_fork_scenarios

1 Like
#59

Apologies but this still doesn’t really address what I’m asking. Yes, I understand the miner ignoring previous blocks has an advantage, and this advantage is made exponentially worse as their share of collective mining power increases.

This isn’t really true though, is it? For example, honest miners are not “doomed to lose” if they have a collective share of 90% of total mining power, right?

It’s still unclear to me what you are advocating for. Please correct me if I’m wrong, but in Bitcoin mining, or any longest-chain consensus mechanism, you can’t force miners to build on previous blocks, right? The reason miners do build on previous blocks is that the incentives guide them to do so when mining is sufficiently decentralized.

So what, specifically, are you proposing? This seems like a symptom, not a cause, of mining centralization.

#60

I suggest it’s about time to move on from the medium of a forum board to a community call with people like @jude who can help address these open questions. At least to me, it feels like we’re going in circles on the last few posts.

2 Likes
#61

How about next Friday, using the SIP call with you Matty, could be a good space for it? Allocate enough time for presenting key findings from reports, and we can get into proper discussion and questions?

1 Like
#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