Below is information about the problem and solution of the current sponsorship and minting system.

Qortal's sponsorship and minting system is our attempt to solve the issue we see in the blockchain space with PoW and PoS where money buys power over the network. We are not claiming that our system is perfect, but the beauty is that we can modify the system as needed. Currently any account that is level 5 or higher (including founder accounts) is able to sponsor up to 5 accounts at one time. There is no limitation to the total number of accounts each level 5+ can sponsor. It takes a sponsee 7200 blocks to reach level 1 at which time they can create their own minting key. The problem we have run into with the sponsorship system, is that some level 5+ accounts are here for personal gain, and not the common good of the project. We have seen a few bad apples create multiple accounts for their own gain that they self sponsor, and either keep for minting themselves, or are selling to the public (primarily in the Chinese community on WeChat app). The next issue is with the minting system itself. Currently we are able to assign multiple accounts to each node. Although we would like to see one account per node, there is nothing securing this ideology in code at the moment. So essentially these self sponsored accounts are able to make more accounts, mint off the same device, and 'game' the current system.

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. Nor would it affect transactions per second and shouldn't really affect scalability. Nodes can verify these proofs almost instantly.

We will be modifying the way the sponsorships function by randomizing when they can take place so that automated creation of sponsorship keys is no longer possible. it will also no longer be possible to remove your own key in order to create a sixth sponsorship key as we've seen the bad apples do. We will likely be opening up sponsorship assets to be able to be given to accounts of level 3 and higher to give more people the ability to sponsor. Two algorithms will decide randomly when the sponsorship assets are distributed. The account MUST MINT in order to have the potential to obtain a sponsorship asset.

We will be adding in the necessity for a mempow nonce submission along with the existing minter signature submission. We will tweak it so that the mempow takes enough time that only 2 account signature submissions may take place from any one node (maybe 3 with a really fast computer, but in most cases the mempow runs about the same no matter what device it runs on). This will successfully limit the amount of minting accounts that can be run on a single node, and thus retroactively remove the ability for many self-sponsored accounts to run their minting keys.

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's proof of work algorithm is limited by the throughput on device's RAM, so buying faster or even specialized hardware doesn't generally increase the number of accounts that can exist concurrently on that hardware. Limiting by hardware like this is good for the network as it means that people gaming the system will be forced to run an equivalent number of nodes, which strengthens the network. Right now there is no limit, but there could be very soon if we choose to go with this approach. The main reason we might not want to implement this is that the proof of work calculations will slow down the node and computer it is running on. We need to decide if the impact is too large.

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://qortal.uk:8080/builds/qortal-2.1.0-PoW.0.jar

Here's an https version: https://cloud.qortal.org/s/G8GL3WYNiW2dBS2/download/qortal-2.1.0-PoW.0.jar

We are looking to get some feedback on it before spending lots of time implementing any limits. Just feedback on CPU and memory usage really. Also, in the logs you should see entries like this:

```Computed nonce: 23449. Time taken: 40518 ms```

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 specs of your machine. Then he can start collating data.

We have a Telegram channel https://t.me/qortallogs and Discord channel #mempow-testing

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 "Computed nonce").

Log file is in ``%localappdata%/Qortal/log.txt.*``

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.