Proposes something similar except stacker support comes in only after a 7-block fork. Decred makes it’s a 1-block decision.
Interesting. I guess at that point the question becomes, what is the value to the network in continuing to allow miners to create <7 block forks?
I’d argue that there’s little to no value in allowing those forks (Assertion #1 above), while the cost is huge b/c it exposes a vector for manipulation. So perhaps the best and easiest route to address Orphan MEV is to simply amend Sip-21 such that stackers determine the chaintip every block?
1 Like
I mentioned in a sibling comment thread that if there are B Bitcoin blocks between two Stacks blocks S and S+1, then the winner of Stacks block S+1 earns B coinbases.
This gives me an idea: what if they only receive coinbases for Bitcoin blocks without sortitions? The reason it’s not unprofitable to orphan blocks in Stacks is because the miner doing the orphaning (the “Entity”) is going to receive their coinbases anyway. If that weren’t the case, then the most profitable course of action for the “Entity” would be to confirm the highest chain tip.
EDIT: I was mistaken – it is already the case that the winner of Stacks block S+1 receives coinbases for only the Bitcoin blocks without sortitions. If a Bitcoin block between Stacks blocks S and S+1 had a sortitions on a different fork, then the winner of S+1 does not earn a coinbase for it. So, we’re already at the place I described.
1 Like
I like the direction you’re going but want to make sure I’m clear on what you’re suggesting.
Let’s say Miner X mines Stacks block S at Bitcoin block B. This block builds on Stacks block S-1 at B-1 and is the tip of the longest chain at the time that it’s mined. Miner Y then comes along at Bitcoin block B+1 and builds Stacks block S’ on top of S-1. They later defend the fork such that S’ becomes canonical and S is orphaned.
Under the current system, Miner Y gets 2 coinbases for block S’, while Miner X gets nothing for block S.
Under your suggested change, Miner Y would now get 1 coinbase for block S’, while Miner X would still get 0 for block S? Is that correct?
Given my above edit, an alternative idea could be that Stacks does not award a coinbase for any sibling blocks. The order in which Stacks blocks at height S are mined is well-defined. If Stacks block S has a sibling block-commit, then the system could just not award S’s miner.
@jude I like it, but I would go a step further and say that S-1’s miner still gets their coinbase, even if S-1 does not become canonical. So basically, the decision rule would become: if you mine from the chaintip, you get a coinbase(s). And if not, you don’t.
At first it may seem weird to pay miners for blocks that didn’t end up in the canonical Stacks blockchain, but I think it’s fair and incentive-aligned with what the network should want. Miners can only control what they do when they win sortition. They can’t control what happens to that block afterwards (unless they control >51% of the network). So if they mined off the chaintip, then they did their job and should get compensated. And if they didn’t, then they shouldn’t (as you suggested above).
More importantly though, paying out those orphaned miners slams the door on The Entity’s ability to defend its monopoly. Currently it’s free for The Entity to create/defend their monopoly, so of course they do so. Your change is a great step in that it creates a cost to defending that monopoly; if a new miner tries to enter the pool, the Entity will need to forfeit money in order to lock that miner out. Clearly that’s not short-term optimal for The Entity, but could it still be medium/long-term optimal? That depends on how you assess the value of the monopoly and the expected cost of defending it, but it certainly might be. Who knows how The Entity (or anyone else who gained 51% control) would assess that, but I do know that they would still have the option to lock other miners out of the pool, so long as they’re willing to pay the cost.
If you pay out the orphaned miners, then that option is gone. A controlling miner simply does not have any levers to censor the payments of other miners, and their only rational choice is to mine honestly.
Keep in mind that a malicious node could mine a block and then never publish it. The rest of the system would see the block-commit, but it would be unknown as to whether or not the block exists (after all, someone could have just created a throw-away block-commit transaction).
Any scheme that pays STX to someone for mining atop the canonical chain tip must ensure that publishing that Stacks block is a pre-condition for getting paid. This makes it challenging to pay miners who mine Stacks blocks that are later orphaned – somehow, the fork that orphaned them needs to be forced to acknowledge the existence of that orphaned Stacks block. That’s why I originally proposed the block pre-commit system, which does this.
Gotcha. So if “validating” a block-commit is not something that can be done automatically in the code, then returning to the suggestion by @jonko above, is that something that stackers could do? And if so, is there a good reason that they’re only asked to do so (in SIP-21 anyways) after a 7 block fork rather than simply doing it every block?
I guess another way to put my question is, could stackers do the job that pre-commit voting is intended to do? My main concern about pre-commit voting is that (if I understand it correctly) it may end up as just another vector for a controlling miner to wield monopoly power, whereas stackers should be more impartial on average and therefore more likely to vote honestly.
I think it’s of paramount importance to keep block production separate from ownership of STX. Otherwise, stackers are just stakers and Stacks is a PoS chain – the already-rich decide who (if anyone) gets to mine, and have the power to do things like require that miners grant them a share of their coinbases to ensure that the STX rich get richer.
1 Like
I’m open to other solutions that don’t involve stackers, just think it’s important to definitively slam the door on The Entity’s monopoly power. Otherwise we may end up back in the same degenerate equilibrium we’re in today, only w/ The Entity extracting a bit less money.
Admittedly I’m out of my depth when talking about low-level details of the Stacks blockchain, how blocks get published, etc., but I have to say I still don’t really understand this part:
Any scheme that pays STX to someone for mining atop the canonical chain tip must ensure that publishing that Stacks block is a pre-condition for getting paid
I guess I’m unclear on why this is hard. Is it really not possible to write a piece of code that would validate that a miner has published his/her Stacks block? At the very least it seems like you could check for the extreme case that you mentioned, where a miner simply created a throw-away transaction?
Pertaining to SIP-21: what is the reasoning that selects the fork length of 7 as the length before stackers should intervene?
Assuming stacker’s intervention can fairly referee the correct fork at length 7, what’s stopping stackers from refereeing correctly at lengths 6,5,4,3,2, and 1 ?
If there exists a forking strategy that grants forkers an economic advantage then eventually coalitions of miners will form, orphaning each others block while vying to create their own proprietary 7-block forks for stackers to tie-break. If stackers can decide fairly then what is stopping them from doing so at fork lengths 6, 5, 4, 3, 2, 1?
If stackers decision can be bribed/corrupted when deciding a 1-block fork, then it seems it can also be true for refereeing fork lengths of 2, 3, 4, 5, 6 or 7. Unless there is special property at fork lengths of 7 that prevents this. What is the logic behind choosing 7?
2 Likes
This is the case where the block producer could be accused of withholding the block, while the block propagator could be accused of orphaning the block. How can you tell the difference in order to determine why the block did not propagate? What the litmus test to determine this?
One general 5000-ft-view approach to solve this is that sortition participants must provably have a block that is referenced that can automatically be dereferenced on demand by anyone. Otherwise that participant cannot be declared the winner of the sortition.
I’d like to propose the following:
Miners have stricter requirements for accepting the longest fork. Works as follows: suppose miner Alice is building off of the chain tip block S. If miner Bob is the orphaner and proposes a longer fork with block S’ looking to displace block S, it must be required that the amount of btc committed for S’ must already be greater than that of block S. Otherwise bob’s fork is not accepted by Alice. In a sufficiently connected network of honest miners, Bob is forked off into his own chain state.
This may or may not completely solve the issue of monopoly mining but might a step in the right direction:
-
if the profit margin of block S is already very slim, Bob in his attempt to produce a acceptable S’ may be doing so at an economic loss and therefore there is no economic incentive to produce such a fork.
-
this will incentivize all miners to produce an aggregate bid close to market bid of Stx/btc. After all, their margin is another miner’s opportunity. This also solves the price dislocation we currently have in the market price of the block reward.
-
if block S is actually being withheld, other miners, given time, can route around that by slightly out-pricing that block and recover the block reward. Therefore block producers are incentivized to quickly propagate their block.
Has this idea been explored?
1 Like
@jonkho Jude suggestion Orphan MEV - #10 by jude to not reward any miner that does orphan a block goes in the same direction of decreasing the profit for orphaner.
+1
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
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?
