Miner Centralization

I don’t agree it’s merely aesthetic. Right now, STX can to a great extent serve a requirement I often hear from potential new adopters: Being able to run smart contracts “on Bitcoin”. The current STX ecosystem makes BTC holders first-class citizens who can probabilistically convert their BTC to STX right through the blockchain protocol without any additional requirements.

With the proposed change (as I understand it - to me there were some open questions) STX would move more towards the gazillions of smart contract platforms where you can buy yourself in in order to run smart contracts.

Thus, I think we would lose an important characteristic that makes STX unique.

Maybe your proposal can also work if it is provided as an option in addition to direct (BTC to STX without any hoops and loops) PoX mining?

1 Like

You don’t buy yourself in to mine. You still pay btc to mine. The stx is only used as collateral / as a backstop. Assuming the miner is honest and sends the tx when he wins the block, the stx isn’t even used at all. The collateral is only necessary so that the miner can be punished if they do not produce the block. In fact, you only need a collateral that exceeds the amount you’re bidding in btc at any given time. That means the amount you’re bidding in btc across blocks far exceeds the amount of collateral you ever need to hold. This is very much a btc driven mining protocol and very close to the existing system. It just has much lower fees and levels the playing field for miners of every size.

There’s no SIP for one yet, but Daemon Technologies is working on one. Stacks 2.1 adds two missing pieces of the puzzle.

In the example I outlined above, a pool could suffer an irrecoverable failure if:

  • there aren’t enough block-commit signatories online
  • the BTC funds somehow get stolen (e.g. enough keys get compromised)
  • a bug is discovered in the smart contract that governs it
  • the pool becomes dominated by a few whales

The way to rectify these failures is to start a new pool. Also, the upside for pooled mining isn’t limited to the STX block reward. Because the pool is governed by a smart contract, the smart contract can create its own additional incentives for participation, such as:

  • varying the STX distribution (e.g. is is pro-rata? is it granted as a lottery? is part of it invested in a charity or a dev fund?)
  • granting SIP-010 tokens or SIP-009 NFTs to participants, which have non-zero value
  • participation in the pool contract’s governance

Think of a mining pool as a DAO. It does all the same things a DAO would, in addition to getting BTC holders to coordinate crafting block-commits and Stacks blocks.

1 Like

I guess that’s a matter of opinion. While it is true that more code will be required, I don’t think the code is very difficult to reason about. Also, the design space (and business models) for decentralized pools is vast, and adding support for them doesn’t require tearing up the existing consensus algorithm (which has been extensively vetted) with a new untried one.

This is pretty easy to achieve. When you register with the pool, you simply supply a network address (IP address, DNS name, API endpoint, whatever) through which your pool client will be in touch with other pool clients. It is obviously possible to build robust p2p networks this way – Stacks (and Blockstack before it) have operated as such for years.

And replacing the tried-and-tested consensus protocol with one that isn’t even spec’ed out (let alone audited or implemented) is somehow less risky? :wink:

1 Like

Yes you do – staking the STX this way is an opportunity cost. You said so yourself up-thread. Also, how much STX needs to be locked up to participate? Do you have concrete numbers?

The staking opportunity cost is on top of the main cost, which is the sending of the BTC.

Remember, you send the same BTC per block on average, so what you sacrifice in terms of BTC is the same.

It would be low, just enough to cover the number of outstanding bets, with a safety factor for price movements. So if we use 2x as the safety factor, and we assume that bets are of size 0.004, then one would have to have 0.008 BTC worth of STX as collateral per outstanding bet, which would be about 500 STX. If a miner can have up to 100 outstanding block bets at once (the time window for winner selection), then the miner would have to have 50,000 STX as collateral.

Exactly – you have to buy your way into mining by paying the opportunity cost of bonding your STX, which is what I believe @blindcite was saying (and you were contesting).

It sounds like rich miners can just buy up all of the slots by partitioning their STX into small miners that they control? If so, then this doesn’t appear to make mining any more accessible than it already is. Also, what happens if there is more STX available to bond for mining than there are available? Fixing the price of slots to be a function of BTC (instead of miner demand) isn’t really viable, since that just pushes the problem towards off-chain solutions for acquiring slots at their fair market value (but by doing nefarious things, like bribing miners off-chain to exclude other would-be miners’ attempts to bond their STX).


Jude, with 5 miners currently mining at their current rate, 50,000 stacks would be required for each miner and only 250,000 stacks would be required across all miners. This is an insanely low amount of collateral. It’s not even a concern. I feel like we’re crossing wires here.

Jude, you can dislike the proposal but I am asking we get on the same page for a few things and work with actual numbers. Being worried about 250k of collateral for 0.02 btc per block worth of mining is missing the point imo.

I’m trying to understand your proposal, @shea256. Asking how it works under various adversarial settings is an attempt to do this.

1 Like

Ok great, good to know, I was a bit confused because I thought you were criticizing the proposal without approaching it with an open mind.

My apologies if my explanation wasn’t thorough or clear enough.

I will come back and explain all of this more clearly.

Thanks for starting a vigorous and much needed debate @shea256 ! Agreed that the ecosystem should view the state of mining as an existential threat: it’s hard to imagine Stacks being a top-10 project with just a handful of miners.

It might be for you but needn’t be for others. On paper, I agree that by the framing above, one might say Ethereum and Stacks have similar miner centralization. But in practice, the raw number does matter. First, the effort and communication overhead for 3 solo miners to coordinate (in case of Stacks) isn’t the same as that for say 3 large pools in Ethereum or Bitcoin. Second, perception does matter: casual users, developers or investors looking at number of miners on Stacks will compare it against number of miners on other networks, and will judge the project on that basis – whether you like it or not.

Besides, we should be striving for more miners and more independent entities they represent: some of the comments here make it seem like one has to come at the expense of the other, that needn’t be the case.

My attempt to summarize the different proposals in this thread so far:

  • From @shea256 : rather than send burn commitments, miners put up STX collateral to signal intent to mine. Only the winning miner actually spends BTC. There’s potential security concerns because of a circular dependency on Stacks: previously Stacks consensus is only dependent on Bitcoin transactions; in this scheme Stacks consensus would take a dependency on state on Stacks
  • From @GM-Chung : place a cap on miner BTC commitments. This has negative implications for Stacking yields because of higher Bitcoin transaction fees.
  • @XanDtikoff 's now withdrawn SIP that proposed changing the coinbase rewards: there was some confusion around the SIP’s goals. It seems the primary goal was to increase the security budget and unclear if it would have had any impact on number of miners.
  • @muneeb et. al are working on another proposal (I’ve seen it referred to as the “dust mining SIP”). It’s not published yet but my understanding of the basic idea is to create two classes of miners: one that mine regularly like today, and another who would just be sending dust BTC. And the consensus algorithm would basically pick a dust miner something like 10% of the time. This is similar to GM’s proposal in some regard, but limits the impact on Stacking yield. Did I get that right?

This is all in addition to the already planned changes in Stacks 2.1 which would enable easier creation of decentralized mining pools.

Ryan for your proposal, I think the key question is around security right? The other details, while important, seem downstream of that: as in, unless there’s a path to make the VRF changes dependent on Stacks state without compromising security, the rest of the details wouldn’t matter? If so, perhaps we should narrow the discussion on that first?


Yes I think that’s right.

From my perspective, if my proposal can be implemented securely, then it should be preferable.

That said, I wouldn’t want to push it forward if there were security issues.

If that were the case, I would support @GM-Chung’s proposal to put a max cap on each BTC commitment.

This deserves more emphasis, I think.

And besides, wouldn’t a more complete way to think about it be to measure the cost of waging such an attack from a starting position of 0? Currently good network actors colluding with one another to become bad actors is certainly a threat, but it seems like less of one.

How much would it cost to spin up 4-5 stacks miners and take control vs 4-5 more large eth mining pools? I just don’t think Stacks is anywhere close to being in comparison right now.


Yes this is an excellent point.

A new miner coming in to mess with the chain is a different attack vector than current miners colluding. Both need to be addressed.

Right now a miner could spend 3 bitcoin and make half of the blocks empty for a whole day, which would effectively double transaction confirmations.

This is an issue.

That comes back to boosting the security budget or adjusting the model.

1 Like

I keep reading that single transaction blocks are the fault of an anonymous miner who won’t upgrade. We’re already getting knee capped on this, just unintentionally.


Mining STX via PoX is concentrated to a few miners because mining is competitive, where the more competition the less immediate, arbitrage profit there is to extract. Given current BTC/STX exchange rates, and STX block rewards, there is a definitive maximum aggregate bid breakeven point that every miner shares in common and can calculate ahead of bidding.

Due to this, miners with bigger pockets can afford to continue bidding to retain their turf when aggregate bids rise so that overall mining is at breakeven or at a loss. No miner can mine at a loss forever, but larger miners ca do this for longer periods of time than smaller miners, meaning they can box out smaller miners over time.

I don’t see how the original proposal changes this. Even if “miners should only send bitcoin transactions once it is clear that they have won the round”, that does not prevent big miners from effectively pricing out smaller miners.

By reducing total BTC transactions fees spent, all that does it increase the breakeven cost of aggregate mining in BTC terms (ie a higher number of BTC now can be spent overall on mining given BTC/STX exchange rate and STX block rewards). But while there is a boost to aggregate mining, absolutely nothing prevents this profit from immediately accruing only to large miners, the same exact way profits currently are accruing exclusively to large miners.

Having miners discover price first, then only send a BTC tx when they win, does nothing to prevent boxing out smaller miners by pushing the price discovery up to a point where even if smaller miners did win, they couldn’t afford to send the BTC to win the block rewards.

With that in mind, I want to take a step back, and think about why the same dynamic doesn’t occur in BTC PoW mining.

In BTC mining, miners can compete adding hash power until the difficulty may become so great, that there is no immediate arbitrage profit between electricity costs and miner rewards. In theory, large miners with deep pockets could mine at breakeven or loss, longer than smaller miners could afford to, meaning they can box out smaller miners. On the surface, it seems like the same exact dynamics are at play in STX mining and BTC mining.

So what’s different in PoW vs PoX?

  1. Variable costs of mining BTC
    Electricity costs (and hardware costs) vary wildly by region, meaning different miners have different cost bases. This means that when mining BTC, you have greater variability in what is seen as the breakeven cost. Contract this to mining STX which uses BTC as the mining cost. Unlike electricity, as a liquid asset, BTC’s value does not vary greatly by region, meaning all miners have more or less identical cost bases. Relative to STX mining, the variability of cost bases in BTC mining, introduces an additional vector of miner competition, one that results in a more dynamic set of currently profitable miners, and is uncorrelated to the vector of a miner’s size.

  2. Higher friction to increasing mining BTC capacity
    Mining STX and mining BTC both require hardware - but in STX, once a miner is mining, scaling up mining to a larger size is as simple as sending more BTC. It’s relatively frictionless to be bidding 200 sats per STX block instead of 100 sats. The same is not true for mining BTC - a miner can not just decide they want to be spending more hash power per block. For each increase in has power they want, they have to source, purchase, deploy, configure, and maintain a hardware device for that has power. This again means that the set of largest miners is more fluid, and dynamic in BTC mining vs STX mining.

  3. BTC is a store of value
    Some (many?) miners of BTC may every well not care if they are mining at breakeven or even at a loss, because mining is an anonymous, KYC free way to acquire BTC, which, as a store of value, should appreciate so that they are eventually in profit. This is effectively a “no-KYC” premium some miners may be willing to pay by mining at a higher price vs buying from an exchange. STX is not explicitly a store of value, so there is likely less confidence in miners that even if they mine at a loss today, they will be eventually in profit.

With these key difference in mind, if we want to optimize for increasing the number of STX miners, then there seem to be only a few possible levers to pull:

a. Increase the variability of cost basis of mining STX
b. Increase the friction of being a big miner of STX, relative to the friction of being a small miner of STX
c. Make STX more a store of value

I think c is outside the scope of this discussion, nor what STX should explicitly aspire to. As for a and b…

At first, increasing the variability of costs basis for mining STX seems impossible, it would effectively require charging people different amount of BTC to mine. But one way to do this would be to apply a non-linearity function to disproportionately down-weight larger miner bids.

ie if there are two miners. One miner bids 100 sats, the other bids 10 sats. Instead of giving the first miner a 10x higher probability of winning, if they got less than a 10x chance, then each miner has a different cost basis for a given expected payoff in STX.

This would also achieve goal b, of increasing the friction of being a bid miner of STX. It would encourage more, smaller miners, rather than fewer, larger miners - to a point. At some point, if miners get too small, the portion of BTC they are spending on tx fees that is not getting bid to win STX reduces their profit. So introducing this function means there is an optimal size to being a miner along an efficient frontier. The lower bound governed by BTX transaction fees, the upper bound governed by the degree of the non-linear function. This function could even be dynamically optimized, perhaps by governance vote or stackers, to optimize for a given number of miners.

No doubt, you’re probably already asking what’s preventing large miners from splitting their bids into many smaller bids from different miners.

Well, nothing is preventing them, but there are couple disincentives to doing so:
This would require running a different mining instance which emulates the complications of BTC mining. I believe that currently you can actually run multiple STX mining instances on 1 piece of hardware, but is it possible to require different physical nodes (either on BTC or STX side) to run STX mining?

Due to the non-linearity, the BTC transaction fee portion of miner bids, punishes large miners disproportionately more than small miners! For example:

Let’s say BTC tx fees are 8,000 sats
A miner wants to bid 200k stats, but would be punished for doing so by the non-linear adjustment such that a bid of 200k sats only get an effect chance of winning weight worth 450 (square root of 200k).

Two bids of 100k sats each, would yield a total win chance of 632 ((100,000^.5) **2) in exchange for (100k sat bid + 8k sat tx fee) * 2 = 216k sats

Because the BTC tx fee is a linear cost, it becomes a higher and higher portion of costs the more large miners need to split up their bids. Relatively speaking, this levels the playing level between large miners trying to split their bids into smaller increments, and smaller miners placing their one and only increment to bid with.

I don’t see how having miners only send BTC when they win a block will help reduce centralization - it does not explicitly increase friction for larger miners, nor does it result in any variability in cost bases between miners.

As an alternative, I would propose a function that non-linearly disincentivizes large bids, thus opening the door for a larger number of smaller miners to profitably mine. The specifics of this function could be dynamically optimized, and doing so via stacker governance vote would offer a novel and compelling additional benefit to stacking STX.


Thank you @MattySTX for your detailed proposal. On the surface, it sounds directionally-consistent with what @GM-Chung was proposing by capping the maximum BTC bid of a transaction. I appreciate you taking the time to write up an explanation for why this could work. But, I do believe in both cases, the same end could be achieved by simply increasing the Bitcoin transaction fee miners pay as a function of how much BTC they spend in their PoX outputs.

This is true – you can run many STX miners on a single machine. There’s nothing we can do to stop this, and it’s not a blockchain-specific problem – basically every DRM regime tries (and inevitably and spectacularly fails) to do this as well.

I have a couple of follow-up questions:

  • If there are enough STX miners, then eventually their block-commits will make up a non-negligible fraction of the Bitcoin block space. I would expect this to drive up their expected fees as a function of N, where N block-commits must out-pay what is now the N lowest bidders. How does this influence the choice of the function by which you create mining friction (i.e. whereas here you propose taking the square root)?

  • Could this change further incentivize Bitcoin miners to (a) become STX miners, and (b) simply censor other STX miners’ transactions in the Bitcoin blocks they mine?

  • Is the choice of the function static, or can it be something the market decides? For example, could something like SIP-006 cost voting be used to vote on a new big-miner-penalty function in the future, so tweaks to this function could be seamlessly made without a breaking change?

  • It sounds like the function would need to take into account the relative amounts of BTC the miners spent. That implies that the function has a memory of some kind – e.g. it considers the last X blocks’ total and per-miner expenditures to determine how much extra Bitcoin the miner must part with in order to maintain a target probability. Is this assessment correct, and if so, what would the memory aspect look like?

1 Like

I acknowledge and appreciate that not everyone sees this as a vanity metric. But, if we’re willing to consider mining pool participants to be equivalent to small solo miners (and there’s a case to be made for this if the pool is built the right way), then it seems to me like the user perception issue could be addressed by altering the way the miner pie chart is calculated: the pie chart would represent each solo miner as a distinct slice. This does not require a breaking change above and beyond what is slated for Stacks 2.1.

Also, if the pools are built in a decentralized manner – i.e. participants coordinate in a peer-to-peer fashion to reach a threshold of signatures on each block-commit (and the block it represents) – then the communication complexity of getting participants to collude to break the chain would be very high (almost as high as getting the same number of solo miners to collude). Granted, leaving a pool is likely to be higher-friction than altering your personal mining strategy as a solo miner, but as long as they can exit with their remaining BTC within a known time-bound, I think we can make the case that we’d be substantially better off than we are now with 2-3 miners controlling the majority mining power. Remember, if a pool starts misbehaving and is implemented to use BFT agreement for deciding on blocks, then only 1/3 + e of the participants by voting weight need to stop signing in order to force the pool to halt (and this is the highest possible defection rate; other pool designs exhibit fail-stop behavior if fewer than 1/3 + e participants stop signing).

1 Like

If I understand you correctly - I think we’re saying two sides of the same coin. If you ignore a portion of how much BTC they spend in PoX outputs, and treat it as 0 contribution to winning chance, but pay it to stackers, then that can be an implementation of a cap or diminishing function to punish large miners. That what you mean?

Ex. 200k sats bid with 8k sats BTC tx fee, would become…
8k sats BTC tx fee, X sats assessed “fee”, 200k - X sats bid

To respond to your questions

The larger the number of miners, the less punitive the function should be. This would allow for optimizing for a given number of miners, that balances decentralization with not taking up too much BTC block space.

At first thought - I don’t think so… If the punitive function is built into the protocol itself, then even if you could censor other miners, you’d still be less efficient at bidding the larger you bid. Put differently, this risk exists more so today in the current structure I would argue.

I think it would be great as something the market can decide. Making it user friendly and intuitive to interpret the impact, would be a challenge in additional to technical challenges.

Yes. What makes a miner a large miner is determined by the desired number of miners, and the breakeven point of BTC per STX. For example if 1mm sats = fair value of the STX block reward, and we want to optimize for 100 miners, then the desire average bid per miner is 1mm / 100 = 10k sats. So the function should optimize for miners to converge to this average size. What the right lookback period is, I can’t say. Too short is unnecessary noise, too long and it may have its intended goal when prices change a lot in a short amount of time.

1 Like