Thanks guys. The test pool is at a rip roaring 1.8% diff so it'll find a block in no time.

The question's been answered enough. Locking thread.

Quote for the record. Give me some time to get the money out of cold storage and I'll post a transaction ID once I've sent it.

EDIT: Sent, transaction ID:
https://www.blocktrail.com/BTC/tx/a5ce6d7b133064e08387d16c4800c9c4c730d83a08a443a9a6eaf916d0f749b8

Thanks Herb, that would have been an extremely generous offer. I would have at least paid you 100% pps back for the mining shares you'd have done so it cost you nothing.

I'd prefer you to use the 13333 port for now since that is testing the new code. However as I stated at the time, I make no guarantees regarding the service on that port so will not be doing the same should a problem arise with block submission on that test server, but I'm fairly confident there should be no problem this time. If that lack of guarantee is an issue then please mine on the regular port instead.

The first failed submit block finder has been found and I would like to post the information here so there is a record of his block find for others to validate his claim to a reward and get his acknowledgement that he is satisfied.

The username and associated best ever share address was:
http://solo.ckpool.org/users/1MVshzPJjto9hb2g4WXAsxh1a7772Tkt8f

I have offered a reward of 12.5BTC - 1% being the nominal block find reward minus the regular 1% fee coming to 12.375BTC

Thanks for your show of support by mining on the test server. I hope you get rewarded with a very lucky block for your good universal karma.

Thanks for your show of support, much appreciated.

The show of support is the thing that keeps me going and at least at this stage I won't be throwing the towel in.

I've been working on the code trying to figure out what went wrong and I believe I have it nailed now but I'm too scared to deploy it again just yet.

Instead I've put up a separate pool instance for people brave enough to test it that would prefer to help signal support for segwit for the time being. This will be temporary and comes without any guarantee, even though I've since confirmed I found the bug with the previous code. I'd appreciate it some are brave enough to mine on it instead of the current pool as a show of support. I'm pretty sure you will end up with a block if you find one.

Pool is at
stratum+tcp://solo.ckpool.org:13333

Stats at pool2 version of regular pool
http://solo.ckpool.org/pool2
http://solo.ckpool.org/users2/
http://solo.ckpool.org/workers2/

It is on the same server as the existing solo pool so comes with all the same performance and benefits.

I would call these only moderately loud, whereas the S7 was extremely loud. Not quiet enough to have in your bedroom but okay in another part of your house. I've never had an S9 so cannot comment, but presumably the S9 is just as bad as the S7.

I'd prefer not to, to avoid people claiming they had those addresses and somehow lost access to them and deal with that sort of nonsense.

5.1TH @ 816W at 4700mV.

Just type the username into the stats and check there... I don't ask you to remember the best share, just look up your addresses and compare best share with the ones I posted.

They're both 1x addresses.

Thank you so very much for the kind offer. I may as well take any donation in this regard at the pool address itself
1PKN98VN2z5gwSGZvGKS2bj8aADZBkyhkZ

What's there to denounce? I disagree with Kano on this and have stated so publicly. We've even gone our own directions with regards to pool signalling support for segwit (which I am for.) I've called Kano a prick openly before on these forums because of his personality and cannot argue the segwit case with him any further after countless debates on IRC. However as far as pool operators and coders go, he has been extremely hard working and honest to a fault. Dancing with the devil you know, if you must call it that. If you want to blame anything for my affinity with Kano, you need to go back to the history of my mining code development which I hate to dredge up, and had to decide whether to side with a completely untrustworthy pathological liar with bizarre interpretations of the real world or an honest hard working opinionated prick. Kano's entitled to his own opinion, and I respect it, even if I don't agree with it at times. There's nothing to denounce. All the users on this pool and reading this pool thread know how Kano runs the pool, what his personality is, and what his beliefs are with segwit, and have made a conscious decision to stay here.

Well I take full responsibility for this and it is going to cost me big time  

I've spent the last day doing a root cause analysis regarding the best share being above network difficulty issue as mentioned here before and after the last high diff share and have concluded this is entirely my fault. This was always going to be a risk with running this pool as the development point for ckpool.

I'll summarise what happened here.

The first high diff share was on code that was halfway merged from old and new code giving support for segwit in the pool code but without actually activating it, while still on a bitcoind that was not signalling support for segwit. There was one failed submission of a block that happened concurrently with another block find on the network and there was nothing unusual about failing to submit a block at that time since it would have been a stale block. However it was the lack of debug from bitcoind that failed to tell me that there was actually a problem with the block submission rather than it just being stale.

In my enthusiasm to further update the code to support segwit, I completed the update to the pool code to request segwit block templates (when it activates) and updated the bitcoind to signal said support, along with adding more debug output from bitcoind for failed block submissions. This was a ridiculous error of judgement on my part to persist with the code.

The second high diff share mentioned here it was clear from bitcoind that there was actually a block submission failure rather than a stale block as there was no concurrent block that happened on the network and the extra debug code I added from bitcoind told me as much this time.

I've since rolled back the pool to older safe code while leaving bitcoind to signal support for segwit.

Now I wouldn't expect any other pool operator to simply ignore these failed block solves so I plan to take full responsibility and adequately compensate those 2 users who may have otherwise found blocks. Note that with the corruption, these actually would not have been blocks but I'm willing to treat them as such.

As I haven't altered any of the pool or user stats in any way, you will find your best ever share will still show your best share so it is time for you to check your userstats and see if you have one of the following bestever shares:
382969404792 or 821809472417

Please contact me either via PM or email to sign a verification that you are the owner of the associated address and I will organise compensation. As I have logs of who these belong to, you cannot just email me and say it was you without confirming your address.

The worst thing about this is not only would it be almost all the pool's profit for the last 2 years, the code itself works fine on testnet leaving me soul searching for how to prevent it happening on mainnet, and too terrified to deploy it again any time soon.  As segwit isn't going to be activated any time soon, there is no great urgency to get the code out there, and it does not mean I have to stop signalling support for segwit. I'm tempted to just shut the pool down if segwit activates instead. This may be the straw that breaks the camel's back. I've been increasingly unhappy with the bitcoin mining world at large for a while now and I may just choose to abandon it entirely.

I've never been so embarrassed online and I'm drinking hard liquor and it's not even midday here. Please send me boxes of tissues for I will be weeping for years to come over this incident  

You are not mistaken. The acclaim board shows one block for you.
https://www.kano.is/index.php?k=userinfo

No idea what software that's from; you should seek help from whoever maintains that software or fork or whatever it is since it's not a pool issue per se. and it's not in any software that I maintain.

My post where I restarted the pool for segwit signalling was after that. You can check the ckpool code, it does check_best_diff where it sets the best share before rejecting shares. The only stale shares which wouldn't get tested for best_diff are those that are so old that the pool can't even find the workinfo for them meaning they'd be more than 10 minutes late because then it can't even decode it as a share.

Don't use the nonce link; that's reserved for asicminer tubes anyway. Configure your miner the way everyone else does by pointing it to stratum.kano.is:3333