This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
future_modifications [12/02/2021 18:17] – 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 18: | Line 22: | ||
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. | 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:// | ||
+ | |||
+ | Here's an https version: https:// | ||
We are looking to get some | We are looking to get some | ||
Line 30: | Line 38: | ||
We have a Telegram channel https:// | 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%/ | ||
+ | |||
+ | 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. |