If a pool is willing to use some form of identity to gate access to the pool, I suspect it would mitigate the attack to some extent. But I wonder if such a pool would be able to be competitive with the open market type pools.

What about an invitation only pool?

Every so often, there’s a vague suggestion of having a pool for stackers, for example.

Undisciplined

decentralized mining is sybil attackable.

standardcrypto

This from @aeonBTC may be relevant:

![](https://m.stacker.news/166216)

[source](https://x.com/aeonBTC/status/2121310619916013671)

Scoresby

 posted a thread on delving this last week about the hard problem of decentralized mining payouts 

If I understand it correctly, it comes down to this: if you want to create a mining pool that doesn't have a central custodian in charge of payouts, you probably need to figure out how to pay out everyone who contributed work.

But if you are paying hashers via the coinbase transaction, there is a finite number of hashers who can get paid, and this becomes a major attack vector by which larger competitor pools might try to drive the decentralized pool out of business. 7d5x9's post describes one form this such an attack might take:

A large miner who directs hash at this pool could split their hash across a number of identifies that each are still larger than most of the other smaller hashers. This strategy could effectively "bump" any little bitaxe hashers from getting a payout slot.

7d5x9 calls this the Rich List Attack and describes a number of different ways it can be used to grief a decentralized pool. They then go through a number of ways that people have thought about trying to mitigate these risks, including a 2015 BitcoinTalk post, a 2017 proposal from Chris Belcher, Braidpool, and P2Poolv2.

But then, the person who posted the 2015 BitcoinTalk post jumps into the chat:

Some disclosure first. I’m windpath on BitcoinTalk, so the “most notable” link in your second paragraph is my post from November 2015. I ran a public 0% fee P2Pool node at 

 in those years, and still hold the domain (more on that at the end).

They go on to observe that this sort of rich list attack may be a more effective way for a centralized pool to grief a decentralized pool:

On your closing question, who would mine honestly and grief the payouts instead of withholding blocks. I think there’s a plain answer: anyone whose business depends on hash power staying where it is today. An existing pool, or a big miner friendly to one, already has the hash power, so pointing some of it at a decentralized pool costs them close to nothing beyond slightly higher latency.

 is ongoing and is a great way to learn a bit about yet another reason designing a decentralized mining pool is difficult.

bitcoin

bitcoin_Mining

[7d5x9](https://delvingbitcoin.org/u/7d5x9) posted a thread on delving this last week about the hard problem of decentralized mining payouts https://stacker.news/items/1612542/r/Scoresby. 

If I understand it correctly, it comes down to this: if you want to create a mining pool that doesn't have a central custodian in charge of payouts, you probably need to figure out how to pay out everyone who contributed work. 

But if you are paying hashers via the coinbase transaction, there is a finite number of hashers who can get paid, and this becomes a major attack vector by which larger competitor pools might try to drive the decentralized pool out of business. 7d5x9's post describes one form this such an attack might take:

If we assume:

> * A decentralized pool has no effective “identity laundering” detection mechanism; i.e., a miner can split their hashrate across many pool identities.
> * Slots are finite. Every slot one identity takes is a slot another miner loses.

A large miner who directs hash at this pool could split their hash across a number of identifies that each are still larger than most of the other smaller hashers. This strategy could effectively "bump" any little bitaxe hashers from getting a payout slot. 

7d5x9 calls this the Rich List Attack and describes a number of different ways it can be used to grief a decentralized pool. They then go through a number of ways that people have thought about trying to mitigate these risks, including a 2015 BitcoinTalk post, a 2017 proposal from Chris Belcher, Braidpool, and P2Poolv2. 

But then, the person who posted the 2015 BitcoinTalk post jumps into the chat:

> Some disclosure first. I’m windpath on BitcoinTalk, so the “most notable” link in your second paragraph is my post from November 2015. I ran a public 0% fee P2Pool node at [p2pool.org](http://p2pool.org/) in those years, and still hold the domain (more on that at the end).

They go on to observe that this sort of rich list attack may be a more effective way for a centralized pool to grief a decentralized pool:

> On your closing question, who would mine honestly and grief the payouts instead of withholding blocks. I think there’s a plain answer: anyone whose business depends on hash power staying where it is today. An existing pool, or a big miner friendly to one, already has the hash power, so pointing some of it at a decentralized pool costs them close to nothing beyond slightly higher latency.

The [delving thread](https://delvingbitcoin.org/t/decentralized-coinbase-payout-protocols-dcpp-a-framework-for-discussion/3060) is ongoing and is a great way to learn a bit about yet another reason designing a decentralized mining pool is difficult.