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?
There is no missing data. Yes, there have been some PoX bids but no Stacks blocks. Simply have a look at the hiro explorer:
Block: 98823: - BTC 781163
https://explorer.stacks.co/block/0xbbfee70bb62510383f3663787485dedbf613543437df1dc8e1dfff840e261ae2?chain=mainnet
Block: 98824: - BTC 781169
https://explorer.stacks.co/block/0x4eb22f95e3053375c52dfe704913b760217b7e67f106220773313ce067802b6a?chain=mainnet
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.
There is no data in your dump for block 781165, yet there were PoX block commits. How is that not missing data? What does it mean then?
Example: mempool - Bitcoin Explorer
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.