Not arguing with this so not sure where you’re getting this impression.
2 Likes
If you agree that the former chain is more robust, despite being more “top-level centralized” than the latter, then you’d also be agreeing that “top-level decentralization” isn’t the main criterion for determining chain robustness.
We seem to agree that chain robustness is a function of the number of independent entities making decisions on which blocks to mine (in particular, I’d argue that the function itself maps the set of entities to the minimum set required to corrupt the chain). Therefore, a proposal to make the chain more robust would be a proposal to at least increase the number of independent entities making these decisions.
Your proposal seems motivated by a desire to ensure that if Alice is willing to spend X% of the total BTC for a block, then she gets X% of the decision-making power on what transactions go into it (even when X is small). Today, there’s a high lower bound B on what X can be, since all miners must pay a non-negligible transaction fee. If Alice can only spend less than B% of the total BTC, then she can’t vote at all. You, me, and basically everyone on this thread agree that this is a bad thing.
Now, what would be the least disruptive way to alter the system so that X can be as small as possible? I point out that making decentralized mining pools achieves this. Then, Alice can send her BTC to a shared taproot address controlled by the pool, and participate in an off-chain, pool-determined voting protocol for (a) deciding on which transactions to mine, and (b) signing off on the taproot UTXO to finalize the vote into a public block-commit. The protocol in part (a) would give Alice’s vote a weight proportional to her commitment (i.e. X). Moreover, the lower bound B on X can be made arbitrarily small by including more participants’ BTC.
This all works without changing PoX or changing any of the existing mining mechanics. Moreover, it opens up a vast design space for pool software, where developers compete on ease of use and perks for joining to earn Alice’s business.
Which brings me to what seems to be your main point of contention with this:
If you really believed this, then you would have insisted that the chain with 10 miners is more robust than the chain with a large pool with 1000 voting participants.
1 Like
Jude, I’ll read the rest of your response shortly and respond, but I just want to say that I do agree that the chain with 10 miners is more robust. How are we getting our wires crossed here? Are you misunderstanding what I’m saying?
2 Likes
Really great to see the level of discussion and thought going into this thread.
I agree the issues @shea256 described around miner centralization are a problem - they’ve personally deterred me from mining as well.
Our discussion about miner centralization has mainly focused on the role of miners as security providers and block builders. I’d also like to highlight that mining also serves as a method of distributing new STX. It’s important that this be as fair as possible.
I like that @GM-Chung 's solution tries to align our incentives more closely with bitcoin’s and our vision.
A thought experiment:
Imagine we set a 10 satoshi price limit on bidable BTC per block. At current STX market prices winning a STX block for 10 satoshi would be a really great deal. 10,000 people want to bid. At this point, the limit on horizontal scaling is now becomes BTC block size transaction capacity…roughly 2500 transactions per block. Bitcoin miners select which of the 10,000 bids are accepted and it is in their best interests to pick the ones paying the highest bitcoin transaction fees.
At this point, the bitcoin bid via PoX is tiny compared to the the BTC transaction fees paid to get your bid accepted in a block. The system starts to look less like PoX and more like proof of burn…but instead of burning the BTC (sending it to an unspendable address), it’s being paid to BTC miners.
So what this proposal does is put an upper cap on the amount of btc sent via PoX - the is the max cap times the max transactions that fit in a bitcoin block and give the excess to BTC miners. In this situation, can a BTC miner who is also mining STX essentially mine for free by including his STX mining transaction(s) for free?
Same question about censorship.
I also wonder if there are volatile market situations where a miner could use this as a low cost option on STX. For example, could a miner decide to not send the BTC transaction after winning and be “slashed” if the price of BTC suddenly increased vs STX so that he felt it no long rational to pay the amount he bid?
If the pool determines the voting protocol instead of the stacks consensus algorithm, how do we know anything about the degree of decentralization of the mining pools?
5 Likes
No one should need to die on any hill for Stacks to be successful, Jude!
Also as Ryan mentioned, this is a straw man argument as we all agree on the goal here. Growing top line number of miners is not mutually exclusive to achieving this, but the two should in fact be correlated.
I think the crux is that mining today is unprofitable unless you are a larger Stacker, which means the current system is essentially closer to PoS.
How will mining pools make mining profitable? You will still have the same incentive and game theory that will lead to centralization of a few mining pools.
Why not just simplify things and make the entire PoX work like a single mining pool? It seems likely that will be the long-term outcome anyways. I’m not saying this as a pejorative but genuinely asking if you think this is viable. If it is, that would make communication about decentralization easier and we should just rename a mining pool participant to a miner.
This reads to me like your point is that unprofitability of miners without stacking is a feature, not a bug. While I like the idea of a lower bound on X and would prefer it this way, achieving this mechanic seems to directly lead to centralization and unprofitability. As you mentioned, PoW does not work this way and seems to be doing just fine on decentralization and scale.
Not to mention, can’t Alice still still spend X% over time to bully and knock-out other miners to get X% of decision-making power in the long-term? While the proportion may be different (would be great to see a model on this), the result could be the same or even worse since we will never reach scale in the current model without miners being profitable.
Could you clarify this point? Let’s say Stacks today is at 3 with 7 active miners. Are you saying Stacks today is AS decentralized as Ethereum and could be more secure than Bitcoin? If so, why are we not shouting this from the top of the trees?
2 Likes
Hey Ryan! Thanks for starting this discussion and for the ideas – great to see more community discussion on this important topic.
I think this is an interesting idea. From an implementation perspective it would mean that the Verifiable Random Function (VRF) is implemented on the Stacks layer and not on the Bitcoin side. The Bitcoin layer will not have enough information to pick the leader. I think this has security implications for consensus. I want to think about this more, my initial reaction is that there is some interesting thing here but we need to think about implementation/consensus details and pros/cons.
For the mining decentralization issue, I’ve mostly been spending time on what we’re calling “dust fee mining SIP” (it should be live on Github soon). It can increase the number of miners to 100+. The fundamental limitation that you end up with is actually Bitcoin’s bandwidth. Even with 100 unique miners (not counting pools who pools behind a single on-chain miner) you’d be taking up approx 10% of the total Bitcoin transaction bandwidth per block. I personally wouldn’t want the Stacks layer to take up more than 10% of the Bitcoin bandwidth for mining. So that gives you some upper bound on the max number of miners that can be supported with the current Bitcoin on-chain mining approach. Some mining pools proposals can push this further and make it more decentralized.
Absolutely! This is a mission driven community and so many people are willing to come together and contribute. Love being part of this community 
4 Likes
Thanks Muneeb, and absolutely, this issue is important to me and I’m excited to present my proposal and also create space for @GM-Chung’s which I also think is interesting and has different tradeoffs. That also goes for any other solutions people post, keep em coming!
Yes, exactly. I wouldn’t want this to be implemented if security issues were found, but I think this can be done without such issues.
Thanks for taking the time to think about this further.
At the end of the day, I’d support any proposal that levels the playing field for miners.
If it is critical for us to do the VRF implementation on the Bitcoin layer rather than the Stacks layer, then I’d support @GM-Chung’s proposal.
Otherwise, if we can figure out a secure way to do the VRF implementation on the Stacks layer, I believe that we’d also benefit from the increased amount of BTC going to Stackers via reduced BTC fees.
Both proposals, from my analysis, should level the playing field between miners.
3 Likes
Perhaps to your surprise, I would be supportive of this outcome as long as there are more independent entities in the pool than there are miners today. Remember, the thing we care about is maximizing the smallest number of independent entities required to induce a safety violation. The specific arrangement of voting participants into one or more UTXO chains on Bitcoin is unrelated – it’s an implementation artifact, not a design choice.
Unfortunately, in this thread I’m discovering that I’m working against over a decade of mental conditioning in which we’ve come to erroneously believe that pool participants have less power than solo miners. This is not generally true. This belief is true in the specific case of outsourceable PoW mining (i.e. Bitcoin and Ethereum mining, in which you need a designated operator), but it is not true for PoX, and it is not true for PoS.
If it is, that would make communication about decentralization easier and we should just rename a mining pool participant to a miner.
Yes, this! We can revise our expectations upwards for pools in PoX. Pool participants have decision-making authority on which transactions get mined in a way that they do not in PoW.
This reads to me like your point is that unprofitability of miners without stacking is a feature, not a bug.
As with PoW, mining in PoX is a negative feedback loop. Given a STX price and BTC prices, there’s an equilibrium at which your BTC inputs equal your STX outputs. This is also true for PoW, but not true for PoS.
With PoX, you could stack your STX and lower your personal equilibrium, but an equilibrium, and the negative feedback loop that sustains it, still exist.
Again, the number of distinct UTXO chains (pie slices) you see on https://app.onstacks.com/ need not be indicative of the number of independent decision-making entities. That number could be far higher.
Could you clarify this point? Let’s say Stacks today is at 3 with 7 active miners. Are you saying Stacks today is AS decentralized as Ethereum and could be more secure than Bitcoin? If so, why are we not shouting this from the top of the trees?
There is more to chain security than the minimum number of miners you have to corrupt to break the chain. Things like number of nodes, diversity of the IP routes they represent, amount of BTC committed over time, etc. are also important metrics for assessing chain security (and there are many more metrics than this).
The goal of this SIP is to increase the number of independent decision-making entities in a bid to raise this number, so I’m going to remain focused on this in this thread. Looking at chain security through only this lens, then yes – Stacks is on-par or near-par with Ethereum. But, that’s not really saying much – consistently having 2-3 miners control over 51% of the mining power is not desired, nor something to brag about 
2 Likes
I’m not sure if I’m missing something but if you have one single decentralized mining pool with 1000 participant, he can simply shut down the server and stop the network. It seems to me that you’re much better off with 10 independent miners.
2 Likes
In the world of PoX mining as outlined in my post, there is no server (i.e. no operator). Instead, pool participants’ clients organize into a p2p network to collectively vote on the blocks and transactions the produce. That’s why I referred to them as “decentralized” mining pools, and talk a lot about voting protocols between a pool’s participants. Sorry if that wasn’t clear.
3 Likes
To change topic slightly, @jude what are your thoughts on capping the btc bid size as @GM-Chung suggested? If you want to bid more you can place multiple bids across multiple transactions.
2 Likes
I think it’s a nice idea, but it’s basically equivalent to asking miners to pay a BTC transaction fee that is proportional to their PoX output. I’d expect this to lower the PoX payout, and possibly increase the number of pie slices you see on https://app.onstacks.com, but I don’t think it would change the number of independent mining entities (the pie chart would only give is the illusion that there were more). The rich miners who can afford to mine will just run multiple such entries.
2 Likes
Ok so we agree it should increase the # of mining entities, that’s good.
It should actually level the playing field for smaller miners because there is no longer a “big blind” that smaller miners cannot afford.
And to be clear, with this proposal, miners would still be able to mine with multiple “slots” and they’d appear under the same entity, just as is the case with stacking.
Currently there are 5 big miners and they spend a total of about 0.02 btc per block in aggregate.
On average, they spend 0.004 btc per block each.
Let’s say the bitcoin transaction fees are 0.0002 for these transactions (I’m not sure what they are I’m just guessing off the top of my head, someone can give me the actual figure).
That means that the existing large miners have a btc tx fee overhead of 5%.
A miner that wants to spend half this (0.002 btc per block) would have a btc tx fee overhead of 10% and thus would be quite a bit less profitable than the biggest miners.
At times I’ve seen the miners operating at near 0% profit or break even.
That means that with the current btc fee environment you simply cannot join the miner club unless you up the ante and decide you’re going to pay 0.004 btc per block.
Then everyone else would be 17% less profitable and you’d expect everyone to adjust their spend downward until an equilibrium is reached or you’d expect one of the existing miners to drop out.
The game of chicken would last some period of time until someone blinks.
This is the situation we’ve seen and would expect to continue to see.
I’m not surprised, because I wasn’t being sarcastic. It seems like in the 2.1 model having multiple mining pools is unnecessary and only serves to complicate things. If the long-term incentive is the largest mining pool has the advantage, why not just start out this way?
First of all, my personal opinion is that the problem of miner centralization does not affect the consensus security of the stacks network. In other words, even if there are more than 100 miners in the stacks network, the security is not fundamentally different from now.
Then the advantages of reducing the transaction of the btc network are:
- The transaction fee paid by stacks miners on the btc network can be reduced. The fee is basically a fixed value according to the setting. Up to now, the stacks block height is 62110, and the miners have consumed a total of 113.5 btc on the transaction fee of the bitcoin network (data sourced from Daemon Mining-Monitor
). The cost savings can be used as a positive incentive for miners on the one hand, and can be fed back to stacking users on the other hand
But I personally think the possible drawbacks are:
- Miners need to pay more mortgage costs to ensure their mining rights. In the original design, miners only need to burn btc, and the transaction will be reserved on the burnchain. But now more collateral needs to be locked for block production.
- The process of miner election has changed. The original process is to record the data on the stacks network first, and then decide who is the winner of this election according to the new block of the burnchain. This process change will lead to the difficulty of attacking the election. From attacking burnchain to attacking the network of stacks (maybe my understanding is wrong). This model is somewhat similar to Ethereum’s Layer 2. But for the stacks network, the sorting process requires data retention on the burnchain, so that decentralized verification can be done.
- The occurrence of flash blocks in burnchain will cause miners’ collateral to be confiscated, but flash blocks should be very common on the stacks network, because the average time for miners to generate blocks on the stacks network is at least 10 to 20 seconds.
4 Likes
Yeah we should certainly explore the security implications of the VRF implemented at the Bitcoin layer vs Stacks layer. BTW, the dust fee mining is sort of similar to GM-Chung’s idea i.e., instead of a cap on all bids, it places a cap on bids for 10% of the rewards and the cap is very low: a dust transaction.
What this effectively achieves is that it caps the potential negative impact on the stacking yield. The bulk of the mining dynamics (the 90% of the dynamics) remain the same but the “small miners” are grouped into a new category where they can mine with just BTC fee i.e., just a dust bid.
If you compare this to the idea of capping all bids, then the main difference is that capping all bids can lead to a situation where the stacking yield can drop a lot (a lot more BTC starts going to BTC fees than getting used as BTC rewards). However, with the “dust fee mining” proposal that maximum reduction in the stacking rewards is capped at 10%. However, it can still lead to 100+ new miners.
The math for that is simple. At the rate of 1000 STX per block, you’d allocate 10% i.e., 100 STX per block to the dust fee miners. That’s approx $100 USD per block at STX price of $1. Bitcoin average fees can be lower than $1 these days. (At higher BTC fees, say $2 per transaction you’d see approx 50 miners.) More importantly, as the network grows, at higher STX price the capacity to support more miners goes up even more. I think the discussion for the SIP of adjusting emissions in the bootstrapping phase (coming years) is also relevant here. Because if a SIP like this is adopted and the stacking yield takes a hit then it’d be nice to compensate for it by increasing the stacking yield for the coming years as well. The Bitcoin yield is a truly unique feature of the Stacks network and a high BTC yield attracts a lot of new developers and users to the network. We haven’t started fully tapping into the power of the BTC yield concept. Maintaining a healthy BTC yield in the coming years is important, especially as the network reaches escape velocity.
4 Likes
This is why decentralized mining pools are IMHO a better solution. Even if your proposal made mining more affordable, it doesn’t create very much room for more participants. Namely, the winning miner still has to pay the BTC fee, and that still prices out many would-be miners (also, recall that miners still have to mine consistently even when they don’t win in order to prevent discount-miners from monopolizing the chain). Moreover, something that’s missing from your proposal is the logic that determines how the STX collateral level is determined. I’d imagine that it would fluctuate with miner demand? If so, then the need for miners to accumulate and stake STX is also an economic barrier-to-entry that has not been addressed.
By contrast, decentralized mining pools with taproot would amortize the BTC fee across the participants, so even a transaction fee of 0.1 BTC could be funded by charging 0.001 BTC to the 1,000 participants behind the block-commit transaction (something you can achieve with taproot).
This is not only a predictable outcome, but was known before the system launched. All miners pay a fixed opex in each round, so naturally that puts an upper bound on the number of profitable miners if the price of the inputs (BTC) and outputs (STX) are fixed. The only way around this is to decouple mining participation from maintaining an on-BTC UTXO chain, thereby freeing miners from paying a fixed opex each round. This is achieved by decentralized mining pools, since the opex is shared across arbitrarily many mining participants. This is not achieved in your proposal – each miner must still must pay a fixed opex: either a BTC fee or, as you mention, opportunity cost of staking their STX.
People need the freedom to exit pools and form their own if they don’t like how the current pool is working. It’s not only a check on the power of pools, but also a release valve for innovation: if you can build a better pool, the current pools shouldn’t be able stop you. Also, pools as I’ve described them require taproot to work (so you can have lots of participants without creating a massive BTC transaction), so it wasn’t an option to do this when the system launched.
2 Likes
How about making a change to the weighted random function where instead of using the stacked amount directly, you’d use the inverse of that amount as the weight, so that smaller stackers instead get a larger chance to get the rewards, even if they get lesser rewards.
This would discourage large miners, but it would also mean more people can stack with a lower starting fee.
1 Like
Can you link to the mining pools SIP/spec?
I’m struggling to see how this is not a contradiction. If pools are sufficiently decentralized, why would someone need to create a better one?
I’m very happy to see this. Even though I don’t agree with everything on the technical side, your contribution brought life back into this forum, and I would argue that an active community that discusses technical concerns is even more important than the protocol that supports it.
Shouldn’t the winning probability be in proportion to the BTC bid? So the bias towards large miners is created by the BTC tx fee?
If so, could the probability function just be adjusted so it becomes more fair in presence of tx fees?
One might argue that reducing the spent BTC of non-winners is premature optimization as long as the winner can’t be accurately determined. I had a lot of mining transactions where the algorithm determined that I had won. But after weeks without payout, I think it’s most likely that I didn’t. I think the consensus algorithm should first work more accurately to determine the winner before conditionalizing on the top of this.
So anyone who wants to mine will first have to have STX in order to post the “bid to mine” transaction?
I think it’s an important advantage of STX over all the PoS schemes around that there is no chicken-egg situation. No one needs to get past gatekeepers that will sell them STX in order to participate. This is an important factor for a global equilibrium. I’m reluctant when it comes to sacrificing the possibility for every BTC user to participate right away.
1 Like