Pool centralization concerns

There is a Discord discussion about the hazards of pool centralization. (@possum , I attempted to post in the Discord thread but I was then sent to time-out. Posting my reply here)

There is a case to be made for a modified p2pool for RandomXT. The addition of xmrig_proxy to the base node could help revitalize interest in decentralized pool mining. I suspect some percentage of the RandomXM lane is mining with XMR p2pool. Creating (and promoting) p2pool for dedicated Tari RandomX would provide two of the four lanes a decentralized pool solution. If incentives align, both could capture a portion of their respective lanes.

4 Likes

I think p2pool is a fantastic idea. I believe Tari originally had a p2pool implementation for the sha3x lane. I would love to see it brought back and expanded to the RandomXT lane.

P2pool is a time-tested solution that would be a boon to decentralization and network security. With network hashrate where it is, now is probably the best time to explore this and hope its usage catches on.

1 Like

Main problem with P2Pool is scaling. Thats why we stopped supporting it a while back. If you mine on p2pool, you are limited by the amount of utxos. Each miner creates a coinbase for themselves. So if you mine a block with 1000 miners, you need 1000 coinbases in the block.

If do pool mining, you can go 20_000 miners, and when you get a block, there is only a single coinbase. And then at a later stage the pool operate aggregates all your payouts into a single transfer rather than having to pay you out a small share for every single block won.

1 Like

Great to have your input here, @blackwolfsa Glad to see you

If memory serves, the utxo limitation contributed to the p2pool pools being limited in size, requiring multiple smaller pools.

Coinbases per block is capped at 1000 as a consensus constant?

A quick observation on the XMR PoW ecosystem:

XMR has been around for 12 years, and even though p2pool exists, it only accounts for 6.2%. Most of the hashrate is still distributed across various centralized pools:

  • supportxmr: 33.1%
  • nanopool: 23.5%
  • hashvault: 15.1%
  • kryptex: 7.3%
  • p2pool.io: 6.2%

I agree that p2pool is theoretically the more ideal choice. But the fact that p2pool already exists in the XMR ecosystem and miners still don’t choose it is the real question worth thinking about when promoting p2pool.

Tari is still in its early stage. I think rather than building a p2pool, a more realistic approach right now is to have more centralized pools to spread out the hashrate. Even if all the hashrate goes through centralized pools, as long as there are enough pools and the market share is distributed, the attack capability of any single pool will be reduced.

Valid point, and I think both goals are worth pursuing. To that end, Honey Badger’s Discord suggestion for Community Mining Pools would provide additional options to spread out the hashrate.

Most XMR miners don’t use p2pool because they are greedy and don’t care about network health, only their own rewards, as is the case with nearly every PoW chain. Miners have proven they will act in their own self-interest and not in the interest of the network, so we should be doing everything we can to align those incentives.

Centralized pools will spin up when/if profitability increases - they don’t need any encouragement. P2pool won’t happen without a little (or a lot of) help.

One thing we could do that would help bootstrap p2pool and new centralized pools alike is have Tari Universe automatically select the lowest hashrate pool for each lane.

I don’t quite agree with the “miners are greedy, so we need to intervene” framing. Pushed to its limit, it could justify overriding any miner choice at the client or protocol level, which goes against the basic premise of PoW.

Miners aren’t a problem to be solved. They’re part of what secures the network. The fact that p2pool has been running on XMR for 12 years and adoption is still this low is a signal that the product itself isn’t competitive enough, not that the users are wrong. The better path is to build a p2pool miners actually want to choose: better tooling, better support, better economics.

Auto-selecting the lowest-hashrate pool in Tari Universe has its own side effects. A small pool gets routed traffic, grows, then gets routed away, which creates oscillation. It also takes away miner choice, and anyone who doesn’t like it just switches to another client.

What I’m trying to say is, if the product is good enough, people will choose it on their own. It shouldn’t be the option they’re forced into.

I don’t think low p2pool participation can be attributed solely to those factors. I think a larger part of it is lack of education, and miners simply defaulting to the largest pool. And the former certainly is a problem to be solved, in my opinion.

I agree. :slight_smile:

It was my understanding this was the original proposal being discussed. As you say it is the more ideal choice so if resources are being devoted somewhere, then p2pool makes the most sense.

Auto-selection doesn’t take away any miner choice. The user could just go to the dropdown in settings and select a different pool if they don’t like the default. It merely facilitates decentralization in a minimally invasive way.

yes

It can be changed. But it starts eating into the utxos per block. We cant just increase the utxo count infinitely per block. Inputs, outputs, kernels etc are all given a weight that was calculated per their raw size, and then adjusted a bit to incentive good behaviour, like spending an input. We also count the special bytes like the extra data on the utxo, the script size etc.
A block is then limited to the max weight it can be. I think practically it limites the blocks to around 4000 outputs.

3 Likes

Thank you, that’s clarifying.

So what is the verdict? Since P2pool is not suitable for now, is it possible to have our own Community Pool?

@PotR @Honey_Badger

Since p2pool is unlikely to gain wide adoption in the short term, could we consider a Dockerized pool instead?

Setting up a Tari pool today has a fairly high barrier: it requires running a base node, configuring stratum, handling payouts, monitoring, TLS. The combination of these discourages most people who would otherwise be willing to run a community pool.

If Tari Labs or the community could maintain a docker-compose pool template, a regular technical hobbyist could spin up a small pool in one evening. This would mean:

  • Individuals or small groups can easily set up community pools
  • Hashrate naturally spreads across more pools
  • Upgrades are easy, just pull the new image
5 Likes