Absolutely, thats why I posted it.

In my opinion any other method than "shadow mining" has a too high risk of going wrong:

• Broadcast at low-traffic times: You don't know when the next block will be mined. Could be seconds or minutes away (which would give enough time for the attack).
• Set the "do not RBF": You don't know if the miners will honor this field or not. It also does not help against an attacker simply inserting a double spend transaction.
• Double spend risk: It seems every miner uses its own metric to determine the valid transaction. Based on fee will end up in a bidding war. Based on timestamp can work but you don't know which metric the miner will use.

So just making a "normal" transaction is much too high risk and I think everyone working on this puzzle should be very aware of that and have a solid plan in case of winning the lottery!

Double spending in Bitcoin is an inevitable feature of the network, regardless of whether it is legitimate or not.
So how do you solve the problem of a conflicting transaction? well, through the confirmations of the miners. And how can we "win" a conflicting transaction? increasing the rate...
In fact, exchanges usually carry out these transactions to reverse a transaction in which the transaction fee was low and they need to make the transaction faster or even unblock a stuck transaction generating a double spend this time with a higher fee.
So this is part of the bitcoin protocol and there is nothing to do. If someone obtains your private address and makes a transaction before it is confirmed, both transactions will "fight" to form a block first, regardless of which was issued first.

thousands of bots are drooling waiting for your transaction, your hard earned bitcoins will evaporate like steam over a pot
now no one will scan 66 address ddd

I have problems with my Big Navi cards in Windows 10 21H1 too, but it looks strange to me. On my test PC, I have a single RX 6600 which is working without any issues with the same windows and same drivers. The only difference is my test PC runs with Windows Home, but the rig runs with Windows Pro. When I start the rig, without setting clKernel or I set it to 1, it returns me Failed to compile program: clBuildProgram (-11) before the DAG generation, and message after the DAG is:

Please see the full log file for more information:


When I start the rig with -clKernel 0 for the last four cards, it works, but I am getting too high percents of stale and incorrect shares. Also, it is strange because the GPU6 is not Big Navi, but RX 5500 XT. In addition to stale shares reported by the miner, I am getting between 2 and 4%  stale shares reported by the pool. The pool reports less than 1% for my other rigs. Please see a short report for this here:


Another problem I started to see sometimes since I use PM5.8c is two of my RX 5700s with Samsung memory report times higher hashrate than normal, while they are not hashing 2: 8617333.868 MH/s (7), but the watchdog does not restart the rig. The other 2 RX 5700s with Micron memory do not have this issue.