Mining protocol changes to combat pool centralization
Monero mining has been [centralized to 2-3 large pools](https://miningpoolstats.stream/monero) for a long time (recently, the largest pool even briefly exceeded 50% of the hashrate). This unhealthy situation is not going to get fixed by itself. It needs a protocol-level solution. I don't think we should implement [radical changes against pool mining like Wownero did](https://git.wownero.com/wownero/wownero/pulls/369), but I'm proposing a relatively small change to make pooled mining more difficult. The [RandomX dataset](https://github.com/tevador/RandomX/blob/master/doc/specs.md#7-dataset) is constructed from a 256-MiB cache. This cache is expanded from a 32-byte block ID using Argon2 every 2048 blocks (~3 days). I'm proposing the following changes: * Construct the cache by selecting random parts of the blockchain instead of using Argon2. * Reseed the cache every 64 blocks instead of every 2048 blocks. The portion of the blockchain that can be used is roughly ~10 GiB (everything except of prunable data - ring signatures and range proofs). The parts that are used to construct the cache could be selected pseudorandomly based on the seed block ID. The effect of this change on the network nodes would be negligible. They already have all the data needed to construct the cache. However, this would greatly increase the bandwidth requirements for centralized pools and their miners. Miners would either have to run their own nodes or pools would have to provide the 256 MiB cache
Posted by tevador on Feb 16, 2022, 7:53 PM
Tags
Related issues
- I've been thinking about this question a lot recently and have asked my friends for their opinions.
- > There's really no reason console games of that era needed, or even could benefit from 6 cores First: One problem of the PS3 was that i...
- Remote session/task persistence: Detach, preserve, and reattach all active tasks, terminals, and extension processes in VS Code Remote
- Not only Eddie, their account control panels and site in general look like something from the 90s, and it seriously hampers their business.
- Signal don't want you to build 3rd party clients and integrations, they are another fully centralised product meant to capture and lock u...
- The page keeps crashing for me.
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
ux (Network)
I've been thinking about this question a lot recently and have asked my friends for their opinions.
> There's really no reason console games of that era needed, or even could benefit from 6 cores First: One problem of the PS3 was that i...
Remote session/task persistence: Detach, preserve, and reattach all active tasks, terminals, and extension processes in VS Code Remote
Not only Eddie, their account control panels and site in general look like something from the 90s, and it seriously hampers their business.
Signal don't want you to build 3rd party clients and integrations, they are another fully centralised product meant to capture and lock u...
The page keeps crashing for me.
Server-side pagination to make ArgoCD UI a rocket
[RFC] Zero-runtime CSS-in-JS implementation
Mining protocol changes to combat pool centralization
Monero mining has been [centralized to 2-3 large pools](https://miningpoolstats.stream/monero) for a long time (recently, the largest pool even briefly exceeded 50% of the hashrate). This unhealthy situation is not going to get fixed by itself. It needs a protocol-level solution. I don't think we should implement [radical changes against pool mining like Wownero did](https://git.wownero.com/wownero/wownero/pulls/369), but I'm proposing a relatively small change to make pooled mining more difficult. The [RandomX dataset](https://github.com/tevador/RandomX/blob/master/doc/specs.md#7-dataset) is constructed from a 256-MiB cache. This cache is expanded from a 32-byte block ID using Argon2 every 2048 blocks (~3 days). I'm proposing the following changes: * Construct the cache by selecting random parts of the blockchain instead of using Argon2. * Reseed the cache every 64 blocks instead of every 2048 blocks. The portion of the blockchain that can be used is roughly ~10 GiB (everything except of prunable data - ring signatures and range proofs). The parts that are used to construct the cache could be selected pseudorandomly based on the seed block ID. The effect of this change on the network nodes would be negligible. They already have all the data needed to construct the cache. However, this would greatly increase the bandwidth requirements for centralized pools and their miners. Miners would either have to run their own nodes or pools would have to provide the 256 MiB cache
Comments (0)
No comments yet. Start the discussion.