User Tools
future_modifications
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
| future_modifications [12/02/2021 17:58] – gfactor | future_modifications [12/03/2021 17:02] – gfactor | ||
|---|---|---|---|
| Line 18: | Line 18: | ||
| 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 27: | Line 31: | ||
| 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%/ |
future_modifications.txt · Last modified: 12/05/2021 08:29 by gfactor