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
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
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
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.
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
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)
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
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
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
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
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
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
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
Trevor and I both wondered if this could make attack/censorship by a BTC miner easier if only one bitcoin Tx is sent versus by each of the STX miners as happens now.
1 Like
Great thought, but transaction aggregation can work when parties are cooperative. Unfortunately, in the case of mining, the parties are competitive so one couldn’t expect them to have to coordinate on sending a single transaction each block.
1 Like
This could be a concern. I’d have to think about this more. This would be a point in the column for @GM-Chung’s proposal.
1 Like
Which chain is more resilient to bad actors?
-
A chain with a single mining pool that has over 51% of the mining power, but that has 1000 voting participants who execute BFT agreement on the blocks they mine. At least 667 voters must agree on a block’s contents before it can be mined.
-
A chain with 10 solo miners, each with 10% of the mining power
When counting up the number of participants who must be corrupted to break the system’s safety guarantees, the former is far, far more robust.
2 Likes
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