This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
future_modifications [12/02/2021 17:55] – gfactor | future_modifications [12/02/2021 17:58] – gfactor | ||
---|---|---|---|
Line 15: | Line 15: | ||
This it the current (and only real tangible) solution: to use proof of work to limit the number of accounts per node hardware (not IP). In the future we may be able to find a way to limit by IP but that's not included in the proposed solution we have right now. This means that sponsorship acts as the first barrier to stop multiple accounts, and the node hardware itself acts as the second barrier, preventing people running lots of minting accounts on a single machine like they do right now. Qortal' | This it the current (and only real tangible) solution: to use proof of work to limit the number of accounts per node hardware (not IP). In the future we may be able to find a way to limit by IP but that's not included in the proposed solution we have right now. This means that sponsorship acts as the first barrier to stop multiple accounts, and the node hardware itself acts as the second barrier, preventing people running lots of minting accounts on a single machine like they do right now. Qortal' | ||
+ | |||
+ | This algo is GPU and ASIC resistant. It shouldn’t really be possible to game it because it’s limited by the speed of writing to/from RAM. So it’s the throughput rather than the amount of RAM. | ||
You can run this custom JAR I made to simulate the additional system load that would exist if we were to switch to such an approach: http:// | You can run this custom JAR I made to simulate the additional system load that would exist if we were to switch to such an approach: http:// | ||
Line 28: | Line 30: | ||
We have a Telegram channel @qortallogs and Discord channel # | We have a Telegram channel @qortallogs and Discord channel # | ||
- | |||
- |