Qortal Project

The future of blockchain platforms

User Tools

Site Tools


future_modifications

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
future_modifications [12/04/2021 18:38] gfactorfuture_modifications [12/05/2021 08:29] (current) – [Additional Info] gfactor
Line 10: Line 10:
 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. 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's reward. The idea here is that it's not possible for multiple minting accounts to coexist as there won't be enough "hardware time" for them all to generate the required proof. Every node on the network can validate this proof very easily, in the same way Bitcoin nodes form a consensus on the next block signer. FYI: we would not be using a PoW that leads to expensive hardware nor changing the block rewards system as we know it. +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's reward. The idea here is that it's not possible for multiple minting accounts to coexist as there won't be enough "hardware time" for them all to generate the required proof. Every node on the network can validate this proof very easily, in the same way Bitcoin nodes form a consensus on the next block signer. FYI: we would not be using a PoW that leads to expensive hardware nor changing the block rewards system as we know it. Nor would it affect transactions per second and shouldn't really affect scalability. Nodes can verify these proofs almost instantly.
  
 ===== Solution ===== ===== Solution =====
Line 50: Line 50:
  
 You can type `%localappdata%/Qortal` into the top bar in the file explorer, push enter, and it should take you to the folder that contains the logs. You can type `%localappdata%/Qortal` into the top bar in the file explorer, push enter, and it should take you to the folder that contains the logs.
 +
 +How many CPU cores would this PoW require? In theory it shouldn't need more than 1, because the RAM throughput caps the amount of CPU that can be used. But we'll know more soon. It's really too early in the process for me to be able to know the answer for minimum RAM. The only way to know for sure is to run the PoW test JAR on a machine with those specs, and then post your log file in Telegram channel https://t.me/qortallogs or Discord channel #mempow-testing
 +
 +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.
future_modifications.txt · Last modified: 12/05/2021 08:29 by gfactor