There may be two reasons for this, but both are of the similar nature.
It may be that you are mining solo and see, say, 3 entries about the reward for the found blocks in the explorer. But at the same time, the balance on the address is equal to the sum of rewards for just 2 blocks. The question is, what to believe?
This happens because the Katnip does not fully take into account the Kaspa block reward logic. The payout for the block you found is not given to you by the block you found, but by the blocks following it — those that made your block their parent. Each of them gives you a reward for the found block, but in the end, after the network reaches a consensus regarding the position of your block and its descendants, only one of these reward transactions remains valid — the one that executed by the block which turned out to be the element of the so-called selected chain, the "barebone" of the DAG. The remaining reward transactions are discarded, and the rewards accrued by them are not taken into account by the network (for more details, see Merging and rewards).
However, the explorer does not monitor the consensus state, because
And the node in its current version does not provide the explorer with such information in a convenient form.
Therefore, you can see records for all transactions in the explorer, both those that were recognized as valid, and those that were eventually discarded. They're reflected in the list of transactions, and you can't tell from there which one is the valid in the end and which is not.
But the address balance in the explorer is taken from the node, where all these nuances are taken into account, so in the end it's the balance that is the true indicator of the number of coins you have at your disposal.
The list of transactions of a certain address in Katnip only includes the incoming ones, that fill the balance of the address. But outgoing transactions that spend coins from that address are not shown in the list, so if some of coins have already been spent then the address balance will apparently be less that the sum of balances of incoming transactions.
To know if this or that of the transaction outputs have been spent you should click the ID of that transaction in the list and look for the Spents (N)
line in the transaction description header on the appropriate explorer page, where N
is the number of subsequent transactions that were spending UTXOs of the transaction in question. If there is that line then at least one of the UTXOs of that transaction has been spent, and that's the reason of the difference between the address's balance and the sum of transactions.
You should have a proper GPU driver installed. Having only CUDA toolkit installed is not enough; moreover, CUDA toolkit is not required unless you're planning to recompile a miner's .cu files.
Make sure your drivers are newer than the minimal supported drivers
Lower you overclock settings, check GPU temperature, update your GPU driver to the latest version. This may seem totally unrelated but surprisingly really helps.
Make sure you don't have two computers with the same name (like HOME-PC
) on your network: sometimes the router's DHCP system settings require that addresses be updated every, say, 2 hours, and the presence of PCs with the identical name causes problems in the IP address re-assignment process. If possible, set a (different) static IP address to each of your rigs.
GPU thread ... crashed: "an illegal memory access was encountered"
messageThis is usually due to a too high overclock setting, try lowering you GPU OC values.
This seems to be something to do with GPU power saving settings. It is suggested to run "Paint 3D" or some OpenGL enabling application in this case, that should address the issue.
It is possible (use -t <number of CPU cores to mine at>
syntax, i.e. -t 4
) but it doesn't really make sense: CPU mining gives you about +1Mh/s per core, while with even as low-grade a GPU as 1050Ti you're getting around 100 Mh/s on it alone. It can also significantly reduce your GPU mining speed if you have few cores (e.g. 2) and several GPUs: it takes a certain amount of CPU power to manage and load GPU threads, and CPU mining aggressively consumes this resource.
You can try running one miner instance per GPU to have as many miner instances as there are GPUs in the rig. Use the --cuda-device
(or --opencl-device
) option to specify which miner instance controls which GPU in the rig.
The default value (16) is good enough albeit a bit conservative. You may choose to set a higher value, which increases a hashrate (people use values up to 4096), but there comes a question: increasing the workload for a little more hashrate has a tradeoff on submission latency, because work chunks are less granular. Latency of say 0.5 sec usually will not effect the blueness of the mined block, but does reduce the chance of being a chain block, thus reducing the chance of merging red blocks and earning their reward. So the system in essence incentives maximal responsiveness (minimum latency). Thus the optimal value lies in the range of 256...1024.
There's an article about the subject.
Consider every time the DAG changes to be a job. This job is updated on average every second. When the user specifies for instance 1% to dev fund, then every 100 jobs the miner mines one job over the dev fund address. If it finds a block during that time, that block's reward goes to dev fund.