This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
future_modifications [12/02/2021 17:55] – gfactor | future_modifications [12/05/2021 08:29] (current) – [Additional Info] gfactor | ||
---|---|---|---|
Line 7: | Line 7: | ||
Qortal' | Qortal' | ||
+ | |||
+ | Don't forget we are dealing with open source software. It’s not as simple as you might think. We can modify the logic but anyone can just change it back by building a custom JAR. For it to be foolproof, the limit has to be **validated** by every single node on the network. In other words, every one of the nodes on the network has to be able to determine if any other nodes have multiple minting keys attached to them, so that they can collectively disallow those minting keys. In practice, this is very difficult, if not impossible. | ||
+ | |||
+ | Proof of work is a viable solution, because each minting account has to include proof that it has used a certain amount of hardware resources to be eligible to be included in a block' | ||
===== Solution ===== | ===== Solution ===== | ||
Line 16: | Line 20: | ||
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' | ||
- | 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:// | + | 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:// | ||
+ | |||
+ | Here's an https version: https:// | ||
We are looking to get some | We are looking to get some | ||
Line 25: | Line 35: | ||
This measures how long it took to compute a nonce at difficulty level 15. If those numbers are consistently higher than one or two minutes, it could be a problem (because it could mean that the node's online accounts would miss out on being included in some blocks, due to taking a long time to compute the proof of work). We’ll need to arrive at the correct difficulty and time limits to use. | This measures how long it took to compute a nonce at difficulty level 15. If those numbers are consistently higher than one or two minutes, it could be a problem (because it could mean that the node's online accounts would miss out on being included in some blocks, due to taking a long time to compute the proof of work). We’ll need to arrive at the correct difficulty and time limits to use. | ||
- | Useful info like ‘computed nonce 112021 time taken 433918’ is helpful. Cal can work out the hash rate from that alone. But if you could send over some more readings (or the whole log file if easier) that would be good too. Please also include the spec of your machine. Then he can start collating data. | + | Useful info like ‘computed nonce 112021 time taken 433918’ is helpful. Cal can work out the hash rate from that alone. But if you could send over some more readings (or the whole log file if easier) that would be good too. Please also include the specs of your machine. Then he can start collating data. |
+ | |||
+ | We have a Telegram channel https:// | ||
+ | |||
+ | ===== Additional Info ===== | ||
+ | |||
+ | The JAR makes no difference right now to any consensus or rewards if you run it. All the JAR is doing is some additional proof of work in the background (essentially wasted computations) in order to a) simulate the system load of this approach, and b) log info about the speed at which it is calculating. | ||
+ | |||
+ | If we were to switch to this approach in the future, these computations would become compulsory in order to mint. They would prevent gamers from being able to run too many minting keys on a single node. But it comes with the trade-off of a lot of extra system load, which you can simulate using the PoW JAR. | ||
+ | |||
+ | Once it's been running for at least a few hours, would be great if you could share your log file (or at least the lines that start with " | ||
+ | |||
+ | Log file is in ``%localappdata%/ | ||
- | We have a Telegram channel @qortallogs | + | You can type `%localappdata%/ |
+ | How many CPU cores would this PoW require? In theory it shouldn' | ||
+ | FYI: This JAR runs proof of work in the background regardless of how many minting accounts there are on the node. So it will run the same with zero accounts as it would with 10 accounts, as it's just a simulation of what happens when proof of work is being done 24/7. |