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.
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.
We have already created a bug report on Immunefi a few months ago describing the behavior of this entity. Besides the obvious censoring behavior of these miners, we have also provided forensic evidence that proves their connection.
It´s a “snapshot” of the Stacks chainstate. Not a single Stacks Block got propagated in BTC Block 781164-781168. Anway, it´s propably the wrong place to discuss such details. Simply drop a line in the discord stx-mining channel. You can tag or dm peters.btc. Thanks!
RE the recent merged-mining style comments here. The proposed Nakamoto release is changing the security model and Stacks blocks/transactions get secured by 100% of Bitcoin hashpower after 150 block window. So any benefits of 100% merged mining are not relevant after Nakamoto release (you are already being secured by Bitcoin hash power for almost all of the block history).
Without Nakamoto release, you could argue that this is good for Stacks security but that argument goes away with the Nakamoto release.
Further, the BTC rewards are an important incentive to keep the sBTC wrapping/unwrapping free.
This is a very different discussion to minimum-bid PoX that deserves its own thread, but I’m curious, how are these attacks happening? If you look at miner centralization aggregated on a daily average, in recent history it has always taken 2-3 miners to achieve >50% collective daily mining power (with mining power measured as sats committed to the vrf).
Are you saying:
a) for intra-day periods of time, >50% of mining power is controlled by 1 party?
b) there is some logic in PoX consensus that allows miners to prevent blocks from being created/propagated until they win a block themselves?
c) some other mechanism?
It seems this is the crux of the issue but it’s not clear, at least to me, what would be causing this other than an organic concentration in mining activity. Nor am I clear on what you mean by “this leads to BTC losses” (other than lower stacking yield but you separately mention that)?
I like the approach, and one additional metric you can look at to combine everything is the F1 score and optimize for that.
That being said, I think the larger issue is designing an approach that knows it will fail when the % of miners engaging in MEV behavior approaches 100%.
A truly sustainable solution should work well even when/if this approaches 90+%. I don’t think this is just some theoretical concern. As one data-point, only about 10% of ETH blocks post-mergeME have been mined without MEV-boost.
A good design principle is that you can’t remove the possibility for MEV, but you can make what miners spend a function of MEV by auctioning off the MEV. Need to think through the analogous situation here, where the MEV itself is derived from censorship.
Thanks for clarifying @muneeb, however my reason for bringing up merge mining is not so much that it is something that needs to be incentivized so Stacks can be secured by all Bitcoin hashpower, but more so to address that if Stacks is successful, then 100% merge mining from BTC miners is at minimum a possible outcome, if not outright inevitable.
Under that assumption, it seems that PoX yield will be non-existent (for the reason the original post outlines and attempts to address). But the proposed solution will not work in a 100% merge mined scenario (as asserted in the OP).
My pushback therefore, is instead of adding the extra complexity here with the proposed solution (which will be obsoleted due to merged mining), perhaps we should look at PoX more as a bootstrapping mechanism that will phase out as the sBTC mechanism phases in to become the yield generating incentive for Stackers.
I disagree with the statement that it is a competitive advantage for sBTC processing to be free. I would argue that the primary competitive advantage for sBTC is its unique interplay with BTC that no other network with wrapped BTC can duplicate. IMO, it is that close integration that Stacks has with BTC which will drive sBTC usage, not the fact that wrapping/unwrapping is ‘free’. I use free in quotes here because there is never a free lunch and anything that is free is just being paid for indirectly instead of directly.
I ask that the free unwrapping/wrapping of sBTC assumption be challenge as introducing a fee market for it and having it transition to being the yield-generating mechanism for Stackers seems like a more elegant solution to the problem presented by OP in that we don’t need to add additional arbitrary parameters to consensus as would be necessary in the proposed solution.
For another advantage of having fees for unwrapping I’ll direct you to my original reply and quote it here:
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.
Yes, multiple miners are under control of one person/entity since months. At the moment all miners except the two smallest ones (SP34 and SP2P). We highlighted all miners in control of one entity in the Dump (link in our first post - scroll down to the very end on the dump-website). As mentioned above, we already provided a forensic proof on Immunefi.
Yes, actually that’s pretty easy to implement and we already built a branch for 2.1 with witch you can “dislodge” other miners to proof our case. You simply have to disable the block downloads (just some variables in the config-file!) if a miner outside of your entity wins a sortition.
There is no block reward for orphaned blocks e.g. 99153 in BTC Block 781607. So every miner outside of this entity burns BTC and isn´t able to proper compensate it with STX block rewards. And yes, a lower stacking yield due to no mining competition.
It is but if we implement a proposal like Jude suggested without a fix for the centralization issue, the last small miners like SP2P would be forced to stop as well.
Can you help me understand this better? The way I see it the MEV miner basically takes a slice of the total pie and the rest of the miners share what is remaining. Wouldn’t removing the MEV miner just increase the size of the pie for everyone (even the SP2P miner) ? If not, can you please clarify why this is the case?