This is an insult to Satoshi who used Windows/Visual Studio in first versions and could be a reason why he left the project.

Ask yourself the following question if you are a Visual Studio developer or any other IDE developer ?!
Would you quite the project you are working on if IDE changed to something you have no experience with and ditch years of IDE experience ?

This is probably a good place to start:
https://github.com/bitcoin/bitcoin/blob/master/src/bitcoind.cpp#L188

AppInitMain()  		// init.cpp
 - Creates the service queue thread (CScheduler::serviceQueue()) which runs "forever" until interrupted and adds it
   to the "threadGroup" (a boost::thread_group which was created in AppInit() in bitcoind.cpp)
   - Inside serviceQueue(), it's a big while-loop, which essentially dequeues and calls the next task in the queue:
         Function f = taskQueue.begin()->second;  // "second" is like the 2nd thing in a tuple, which is a function call.
         // .. other stuff
         f();  // call the actual function

I suspect you'll find it is the derivation path he is using is incorrect.

I'll guess he has gone with the "standard" m/44'/0'/0' derivation path specified in BIP44 and used by hardware wallets etc... most likely used if it was done by a "library". The problem is that Electrum uses a derivation path of m/0

Both paths will generate "valid" public keys/addresses... but they'll be different.

You can set the gap limit with this command:
Or you could create a bunch of new addresses to see if its contained in there:
false: for recieving addresses
true: for change adresses

Are you sure this address was derived correctly? He may have used the derivation path for change adresses?
The standard derivation path for electrum is 0/0/ for recieving and 0/1/ for change addresses (i think).

Electrum has the same master public key that is used in the service you've stated. With that, Electrum will constantly query for transactions in addresses within the gap limit.

For example, your gap limit is 25 addresses. After the initial address generated by default by Electrum, Electrum will continue to look for transactions in the next 25 address. If the next address has a transaction associated with it, Electrum will query another 25 addresses after it, and so on.

why not use the free 12 months trial of amazon aws you can start launch linux os in their ec2 for free and you can start your project to make your own payment gateway. Or use some third party like bitpay or gourl (for wordpress)

The nonce in the block header is a 4 byte integer.  Therefore there are only 4294967296 possible nonce values for any given header. After that, you need to modify the header in some other way to gain another 4294967296 nonce attempts.  Common ways to modify the header are to adjust the 4 byte timestamp or to change the transaction list so as to get a new merkle root.

Yes.

The miner keeps trying new nonce values until they find one such that hashing the 80 byte block header results in a value that is less than the current difficulty target value.  The fact that the block header (which includes the nonce) hashes to a value that is lower than the target is proof that they have completed the necessary work.

Then they build a merkle tree from the chosen transactions and calculate the merkle root.

The solo-miner (or mining pool) typically runs software that makes the decisions.  They can often configure that software in any way that they like.
In the case of Bitcoin, they are required to include AT LEAST one transaction (the transaction that pays the block reward).  Beyond that they can include as many or few valid transactions as they like as long as they don't exceed any size limits on the block.

Wow 

Amazing discovery of a amazing coup. The guy who made this and the guy which discovered it are pure genious.

I am really excited to find out in which priv key generation code this thing is implemented.

The best would be to use replace-by-fee but you have probably not done it.

I you own the output  1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr, you can do "child pays for parent" https://bitcoin.org/en/glossary/cpfp. You spend from
1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr  to another address you own and pay a large enough fee. The miners cannot confirm the child without confirming the parent so in order to grab the new fee, they have to confirm the parent transaction. The new transaction (1 input, one output) will be 192 bytes, so two transaction will be 10094+192=10286 bytes. You paid  41830 satoshi in fees. If you pay now a 100000 satoshi fee, these two transaction will be 141830/(10286)=13.78 satoshi/byte. Still not a lot, it will take many hours or days to confirm (but it would have been instant 1-2 days ago). If you pay 1,000,000 satoshis (0.01 BTC), the combined fee will be 1041830/10286=101.28 sat/byte which should get confirmed immediately (even 60-70 sat/byte should be fine now). See, the current mempool statistics:
https://core.jochen-hoenicke.de/queue/#2d
But 0.01 BTC is quite a lot. Your choice. During weekends, there are usually less transactions and mempool is usually emptier and the running fees are lower. Last weekend it was 5 sat/byte so your original transaction was very close.  But nobody knows how full the mempool will be.