Miner Centralization

SIP SIP: Brainstorm
#14

Yes it is still proportional.

No. A single miner can have multiple bids, proportional to the amount of stx put up as collateral.

Yes this can still happen, but because btc tx fees are reduced from “high regardless” to “pay only if I win” then there is no high “small blind” or “big blind” required to play, to use poker terminology. This levels the playing field between large and small miners.

This effects stacking by increasing the stacking reward. The reason is that the participants in the market equilibrium should be willing to pay more for the block reward as they no longer have to pay btc fees each block. Thus there is a miner surplus that is created and the competition between miners drives up the bid until the miner surplus becomes the stacker surplus. For example, if btc transaction costs are 5% of the amount of btc spent, this update would decrease the costs by 5%, driving the amount spent to stackers up by 5%.

3 Likes
#15

Thanks Ryan, this helps clear some things up. I think miners would pay more per block in this scenario because the expected value per block doesn’t need to take into account capital spent on blocks lost. Unlike now, a miner could bid 99.9% of the block reward in this model and still be profitable.

For the collateral slashing, is that only done in the case that a miner fails to commit their block? Would there be any other scenarios where a miner could be slashed?

3 Likes
#16

Happy to share my ideas in this discussion: Limit miner’s max BTC bid per block for horizontal scaling

Like Bitcoin, PoX is applied by Nakamoto-style consensus, so game theory is applied, and under the assumption that everyone is rational, they get incentives from the network in proportion to their resources.

There is one thing we overlooked here. That’s a resource limitation.

For Bitcoin miners, they buy higher performance miners to maximize their hash rate. Of course, the performance of miners continues to improve over time, but in order to reach a high hash rate in a shorter time, miners scale horizontally by purchasing more miners.

In a similar case, there is a deposit of 32 ETH to participate in the ETH 2.0 PoS verification process. In order to participate as a validator, you need to deposit at least 32 ETH, but even if you deposit more ETH, you will have an equal position, leading to horizontal decentralization.

In other words, in the case of Bitcoin, it is the time factor that limits the computing power, and in the case of Ethereum, 32 ETH.

Let’s introduce it to PoX. We use BTC to participate in the mining process. At this time, BTC has the advantage of being able to easily participate in mining because anyone can easily access it if they have enough money.

However, if we apply the limit of bidable BTC per block to impart fairness to miners, it will naturally induce miners to horizontally scale to obtain larger potions. At the same time, the Stacks network nodes will naturally expand as well.

Of course, compared to before, the frequency of BTC transactions increases, which consumes a lot of transaction fees, which can be bad for Stacker’s return, as Ryan said. However, this is consistent with our vision in terms of helping the Bitcoin network come alive. So from a big perspective, both ecosystems are win-win.

++ If there is a mining software or dashboard with a simple UI/UX for the public, it will be of great help to the mining participation. We talk about easy participation in mining, but in reality, it is very difficult for normal people without expertise to set it up. Such as one-click miner setup tool with auto-mining software upgrade.

8 Likes
#17

A subset of Stacks miners would randomly be determined as potential winners for a given block and then they would post commitments, in this model? Or would it be first-come-first-served slots?
EDIT: might have gotten mixed up between applying the limit to the # of miners who can win a block and applying the limit to the amount a single miner can bid.

1 Like
#18

@ryan Curious to get your thoughts on if this proposal would change your angle at all… pool-participants sharing in the cost of one Bitcoin tx fee feels like a step in the right direction but seems like the poor stable equilibrium would still exist between a few pools and a potential newcomer pool.

#19

As @friedger mentioned, I think we want 1000’s of miners or as many as possible, as can be profitably incentivized to participate.

@GM-Chung I’m thinking both ETH PoS and this proposal of limiting BTC bids to increase horizontal scaling doesn’t really change much since the scaling has a relatively low cost of just spinning up more software instances compared to the more costly scaling of PoW hardware.

I wonder if an algo can be devised that makes it more costly for a rich entity to spin up more instances - assuming extra Tx fees isn’t enough. Like say the higher the total number of miners there are, the lower the maximum allowed BTC per-block bid level. In this way a whale with lots of BTC would not benefit much from spinning up a lot more nodes, and at the same time other new mining entities would be benefit to begin mining, which increases the number of miners and also lowers the max amount of BTC per-block bid allowed for all miners.

And like Bitcoin’s difficulty adjustment maybe there should be a smoothing factor where these parameters are averaged over some number of blocks, if it helps in some way like making short term gaming the system more difficult.

4 Likes
#20

Miners coming and going also affects Bitcoin PoW and this is smoothed/controlled with the difficulty adjustment algo. Can we devise something similar like a "cost adjustment" algo that changes cost limits for all miners based on the total number of participating miners? Eg, it could lower the max allowed BTC bid per miner per block as the number of miners increases and vice versa.

I guess it’s sorta an artificial way of making sure all participating miners have a chance of making a profit per each block even if new/more miners show up.

2 Likes
#21

Rather than limiting bids outright (which discourages whales from entering and not sure that is desirable in the real world) could you segment mining bid amounts into risk tiered tranches much like what you see with risk tiered tranches in insurance captives?

2 Likes
#22

I think most of us don’t have anything against whales, but I think the consensus primary goal is maximizing the number of mining entities and miner decentralization. So if there must be a tradeoff between size of miners and number of miners it’s better to optimize for the latter.
Ideally we will have both big and small miners via mining pools.

4 Likes
#23

Yeah we want both big and small miners. We just don’t want larger miners to have economies of scale. We want the profitability to be the same regardless of scale. And this we believe will increase the total # of miners and thus miner decentralization.

4 Likes
#24

Yes, that’s right. I think this is also a cost, as long as the cost of spinning up a software instance is relatively lower than scaling up on hardware.

So how about differentially paying Coinbase rewards for miners that show low-quality block throughput? If so, miners will adopt a minimal level of hardware. This will act as a kind of difficulty adjustment.

#25

This is literally the problem that decentralized mining pools solve. Get lots of independent people to agree to pool their BTC to form a single block-commit. Unlike PoW, the decision protocols for gathering and assembling that block are independent of the mining power aggregation (i.e. aggregating BTC), which gives pool participants a lot more power in the system than you might expect.

Stacks 2.1 adds support for block-reward-pays-to-smart-contract, as well as full support for querying any Bitcoin block header back to the Stacks genesis block. With these two features, it becomes possible to build a both mining pool contract and mining pool wallet in which the participants not only earn a share of the block-rewards proportional to their BTC commitment (and amortize the BTC transaction fee across participants), but also decentralize the role of the pool operator by replacing it with a BTC-weighted voting protocol between participants for selecting transactions to mine. There’s lots of off-the-shelf implementations of such voting protocols; getting this part to work is easier than it sounds.

Once you distribute the operator role across the participants, the people who contribute BTC to the pool receive a proportionate share in its decision-making ability as well. This puts participants on par with solo miners insofar as deciding the fate of the chain. You can then reasonably count these participants as distinct miners, since a block-commit no longer reflects a single entity’s decision.

If miners aren’t irretrievably sacrificing some resource proportional to the reward each time they attempt to mine, then I’m afraid this is just proof-of-stake with extra steps. Big STX holders can forever price small STX holders out of the market. Unless the BTC chain does something wonky and somehow prevents them from mining when they win (leading to slashing), big STX holders always gain more mining power at a faster rate than small STX holders.

This is not true today in PoX. Rich BTC holders become less rich in BTC by mining by transferring it back into the market for other would-be miners to buy.

The raw number of miners is a vanity metric, and I will die on this hill. The number you should care about is the minimum number of independent entities that must coordinate to gain 51% of the mining power. You want this number to be as high as possible. For Stacks, this varies between 2 and 3. For Ethereum, it’s 3. For Bitcoin, it’s harder to tell since 44% of the mining power is “unknown”, but it could be as low as 2 if these “unknown” miners are really just a single stealth entity.

This isn’t good, but the solution here is to make the accumulation of mining power contingent on fostering cooperation between many entities. You want to maximize the smallest number of independent entities that have to be corrupted to break the chain. This is achieved by decentralized pools, since you only mine with a pool that does what you want, and if it stops doing what you want, you defect and lend your power to a pool that does (or start your own if none do).

7 Likes
#26

So a 51% attack is better if it is a tug of war (mining pools) than a gun to the head (2 or 3 solo miners)

#27

This is really the crux of the discussion to me. I agree with the original points raised, but right now the proposal Daemon has been working on for mining pools appears to do a better job at solving the issues, without introducing as many unknowns. In Ryan’s model, the incentive structure may be a bit better for small holders, but that’s irrelevant if it makes large trade offs in network security. This is where I’d love to see more discussion happen, especially from those with the specific expertise to weigh in on potential security guarantees.

4 Likes
#28

First off thanks Jude for responding to this proposal.

I’d like to point out that by locking up stacks as collateral, and then sending bitcoin when a block is won, these miners are absolutely sacrificing something. First, they are sending bitcoin to stackers on a probabilistic basis. And second, they will actually be sending more bitcoin to stackers because less bitcoin will be lost to transaction fees. Second, these miners have a “cost of capital” for their locked stacks. They are losing out on stacking rewards and thus for every $100 they lock up for a year as collateral, they are paying $10 per year.

In terms of what you call “proof of stake with extra steps” the current system is no different. Miners currently sell stacks to buy bitcoin, which they can then use to mine and receive stacks. Then they do it all over again. In this proposed system, the same would occur.

The collateral is only meant as a backstop to prevent miners from cheating and not sending the stacks when they win. This is not stake-y. It is a “send bitcoin to stackers” system.

Consider for simplicity that you could model the current system as 5 miners each with 20% of the mining pie. Let say they send 0.004 btc per block, regardless of whether they win the block. In this system, they would instead only send the btc when they are randomly selected by the protocol to place the block, and they would on average send 0.02 btc each block. The amount sacrificed ends up being the same. Can you see how the probabilistic sacrifice turns into an actual sacrifice once enough blocks have passed? The # of bitcoin sent to stackers remains the same, more or less, at first glance. But bc tx fees are reduced, the amount of bitcoin sent to stackers actually increases.

This doesn’t reduce the security of the protocol. In fact, it increases it because it allows miners to participate at any size. This should reduce the # of miners that can reach 51%, which is the metric we agree is most important.

4 Likes
#29

Decentralized mining pools are great but they still do not allow the system to grow beyond 5 large miners/pools.

I want to clarify that I am not only in favor of my proposal. I would support any proposal that would eliminate or reduce the bitcoin transaction fee advantage that larger miners have.

@GM-Chung’s proposal is another valid solution to the problem. It evens the playing field between miners, which should allow more entrants, and increase the # of miners that collectively make up 51%.

For example, if the playing field was level, you could see 10 more miners enter the ring that are each 1/10th the size of the current miners. Then the # of stacks miners that control 51% would go from 2-3 to 3-5.

3 Likes
#30

I disagree here. Top level decentralization is important in addition to within-pool decentralization. If you give up on top level decentralization then that’s a sad outcome for the protocol in my opinion.

2 Likes
#31

I’d support either my proposal or @GM-Chung’s as I believe they both solve the issue of miner size advantage via lower btx tx fee fixed cost.

The decentralized mining pool proposals do not solve this issue. They essentially give up on top level decentralization and then push the issue down a level and hope that is acceptable.

I just want us to recognize the problem together and realize decentralized mining pools are great but not the solution to top level miner centralization. Even in the most optimistic case (which is highly unlikely to occur), having 5 mining guilds control mining sounds pretty centralized.

I’m also open to hearing other proposals and encouraged @GM-Chung to post his. It’s very simple and elegant and it doesn’t require any big changes. The only downside to it is it somewhat increases tx fees and thus decreases yield to stackers, whereas my proposal increases yield to stackers.

Either way, let’s get on the same page here.

2 Likes
#32

Jude, to clarify, we’ve always agreed that the most important measure of miner decentralization is the # of miners that collectively control 51%. From my observation, when people say “we want more miners” they are just expressing this thought. So I want us to avoid strawmanning the “more miners would be good” statement because it is shorthand for “when you have more miners, every other miner has less of the pie, and as you bring this to the limit, the # of miners that control 51% increases.”

2 Likes
#33

I read Schnorr/Taproot has brought transaction aggregation to Bitcoin and so I wonder if this could be used to solve this Tx cost problem. Can it be used to significantly lower the total BTC Tx fees spent if there is a large number of STX miners?

1 Like