Yes, 1 million is the starting diff and 500k is the minimum diff. If the shithash service connects for a while and doesn't send anything it probably drops to the minimum.

Welcome to our new miners and thanks to CG and others renting. We pushed above 10PH for a little bit there. Keep on mining

Port 4334 difficulty is set to 1 million, just how freaking high does your rental service want it? You have no control over diff as the user.

Apart from finding blocks, what's the plan?

What's your hashrate and work out what your chance of getting paid at any other pool is.

It's actually a bit lower sorry, I did a rough estimate and diff has risen from when I last checked. It's in in 7700 per day.
4.2gigahashes solves 1 diff 1 share per second.
Current difficulty is 2,227,847,638,503, which means you solve a block on average every 2.2 trillion diff 1 shares. You have 14 terrahash or 14000 gigahashes so you solve 288 million diff 1 shares per day.

You have about a 1 in 1500 chance of finding a block each day. Go elsewhere for advice on shitcoins please.

Rewrite it from scratch in another programming language.

No there is not. The diff of the pool has absolutely nothing to do with your miner's performance - trying to improve performance or luck by fiddling with diff is pointless. If you found 4 blocks on nicehash they were all shitcoins.

You are asking to do multiple things here. Mining solo is as easy as setting up bitcoind, ckpool and then pointing your S9 at it. However "playing with a candidate block" is seriously high level shit that should only be done by people who understand code and bitcoin at a high level. There is no "better" hardware to use, as the only thing that makes it possible to mine a block is hashrate, and the more hardware you throw at it the more chance you have at finding a block. An S9 is likely to solve a block on average once every 5 YEARS. It is likely the hardware will burn out before you actually achieve anything at all (let alone make a profit.) Hope this helps put it into perspective.

Read:
https://bitcointalk.org/index.php?topic=2415854.0

So long as you say what code it's based on, I'm happy. You need to set max block size to smaller instead then by say 15kb.... though the chance of having a full sized moronic 8MB block is pretty slim.

Yes

Ckpool-splns was designed to be used on the ckpool.org pool only so I didn't really add much in the way of documentation for it apart from in code comments, nor tested it in many environments. Thanks for that. Be aware that if you're using the splns fork with hundreds of users, you must leave room in your block size for the generation transaction as well so set block weight in bitcoind to less than the full amount (something like 3.85MB instead of the max 4MB). Bitbucket had a major cloud storage failure of some sort.

Yes we know him and he posts here and he has said many times he is here to stay. The only time his hash disappears is temporarily when someone offers him a stupid amount to rent his hash which only ever happens for short periods.

Yes very nice, pushing over 8 now.

The S9 doesn't contain the official cgminer so you're asking for support in the wrong place. Nonetheless the S9 isn't capable of solo mining by itself; you'll need to run pool software such as ckpool or if you want the level of customisation you're talking about you're going to have to write software yourself.

False positive and google offer no way to appeal against it.

Definitely. In essence they're still mining on just the header of the first block they solve since they can just get out a blank template for work while waiting for the bitcoin daemon (or whatever custom block generator they use) to create a fresh block template for them and then the pool software to distil it down into a merkle tree they need to then send out. It also saves a few bytes but that doesn't matter much since all the current mining protocol messages easily fit into one MTU - though the likelihood of need for retransmission increases as the size of the packet gets larger.

It goes beyond the time taken to sort transactions in the bitcoin daemon to generate a new block template which is an issue in itself and has to work within the limits of scalability of the pool software as well and its ability to send out fresh work to thousands of miners.

Pools also have clients connected to other pools in order to detect a block that has been solved by that pool before it has even propagated on the network based on the block header sent in their stratum (mining protocol) template for new work. As they don't have the full block but have the header they cannot even build transactions on it but can start working on a transaction free template until they get the full block and then create a template for work with transactions afterwards. This is one of the main reasons blocks very close to each other from different pools do not contain transactions. This is also why there was an invalid fork that many pools were mining on for an extended period a couple of years ago - they forgot to check the block was ever valid. They've at least fixed that issue but they will still keep mining empty blocks.

None of my pools or pool software do any of the above since speed and scalability was the reason I wrote new software from scratch so there is very little to gain by doing so, and I've always believed in only mining on fully validated blocks and mining as many transactions as possible. Thanks to Bluematt's fibre network it doesn't take long for full validated blocks to propagate any more and bitcoin core's block template generation is magnitudes faster than it used to be at sorting and creating new transactions. At best working on an unvalidated header can only gain 200ms these days. However that doesn't take into account that the pool software itself used by the bigger pools hasn't been able to scale to the number of clients they're seeing so they still save time in getting new work out to all the miners with an unvalidated block header based template for work.