[∞ YH] solo.ckpool.org 2% fee solo mining USA/DE 255 blocks solved!

[madmartyk]

EDIT: The Europe solo will stay, it just need a bit of time that everybody take a notice on that, maybe
that will be the case with the Hong Kong one either.

If we can Help / assist you in improving the de server, just ask, we will help!

I've had a think about it and I figure what I will do is if the de pool solves a block, that will pay for commissioning a better VPS for it and then I'll deploy a more powerful version of it. The only downside to this is that what's really happening is miners are leaving solo.ckpool.org and going to de.ckpool.org so that even though de is proving instantly popular, the solo pools combined will still only be solving the same total number of blocks.

Uh, yes, that is a thing wich can only be solved by the people who solve a block and donate(!) afterwards.
The other way would be an increase of the pool fee.

Or Donations of the Europe User.... i look in my wallet then.

Right now I have 1 rig on each!!  (even though the US one is only 1.2T)

[o_solo_miner]

Think about the cost and time, con spend on it for just having the user happy.
The future will not be better on diff raise and electr. cost for miners, so it will be a decreasing numbers of
miners in lets say 1 year.

[-ck]

The current DE server appears to be handling things fine so I'll leave it as is for now.

Alas mining with a lower ping time won't find blocks any faster.

Another brief blip in the DE server mining coming up.

EDIT: Complete

[o_solo_miner]

  watching as always, if i could...

[-ck]

I'm planning to bounce the main pool again today for a minor bugfix (despite me saying it wasn't going to happen for a while) but I'm waiting for either the next block find or the heavy hitting rentals to calm down. It doesn't mean I want you to stop hashing, this is just advance notification that there will be a very brief blip in mining coming up.

[madmartyk]

I'm waiting for the 141 blocks solved and that little popup on my screen!! 

[o_solo_miner]

  and i hope it is my Wallet no. on your screen 

[nix_on]

And the next one  

[727miner]

Congrats to 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC  

[madmartyk]

Congrats to 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC 

Congrats!!!

[-ck]

And the next one  

Congrats to 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC  

Congrats to 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC  

Congrats!!!

Code:

[2015-12-18 01:00:03.933] Possible block solve diff 81971938658.699142 !
[2015-12-18 01:00:04.280] BLOCK ACCEPTED!
[2015-12-18 01:00:04.281] Solved and confirmed block 388950 by 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC
[2015-12-18 01:00:04.281] User 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC:{"hashrate1m": "361T", "hashrate5m": "372T", "hashrate1hr": "386T", "hashrate1d": "101T", "hashrate7d": "19T"}
[2015-12-18 01:00:04.281] Worker 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC:{"hashrate1m": "361T", "hashrate5m": "372T", "hashrate1hr": "386T", "hashrate1d": "101T", "hashrate7d": "19T"}

https://www.blocktrail.com/BTC/block/00000000000000000d69be8e223cf97fbffd050d2f099c8de17ddcdd0136e9d6

And  I'd like to point out that block was only 3 minutes after the previous block but was still a full block.

Now I'll be restarting the pool as I discussed earlier.

EDIT: Restart complete. Mine on!

[P4ndoraBox7]

I think ill join the flow in january with an S4 and S5.

[727miner]

I think ill join the flow in january with an S4 and S5.

Never a better time than now 

[P4ndoraBox7]

I think ill join the flow in january with an S4 and S5.

Never a better time than now  

Here we go...Just joined. S4 + S5, little overclocking, 3,600 GH/s.

Edit  ; changed my mind. I prefer to wait in january.

[-ck]

Just dicking with the tube proxy on port 3335 at the moment so you may notice some up and down action.

EDIT: The dicking is over, tube proxy back online working as it was previously.

[Gws24]

Code:

[2015-12-18 01:00:03.933] Possible block solve diff 81971938658.699142 !
[2015-12-18 01:00:04.280] BLOCK ACCEPTED!
[2015-12-18 01:00:04.281] Solved and confirmed block 388950 by 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC
[2015-12-18 01:00:04.281] User 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC:{"hashrate1m": "361T", "hashrate5m": "372T", "hashrate1hr": "386T", "hashrate1d": "101T", "hashrate7d": "19T"}
[2015-12-18 01:00:04.281] Worker 1ASM3Rj5FkyGY7hNZBHbkmSf6sj1suDnaC:{"hashrate1m": "361T", "hashrate5m": "372T", "hashrate1hr": "386T", "hashrate1d": "101T", "hashrate7d": "19T"}

https://www.blocktrail.com/BTC/block/00000000000000000d69be8e223cf97fbffd050d2f099c8de17ddcdd0136e9d6

And  I'd like to point out that block was only 3 minutes after the previous block but was still a full block.

Now I'll be restarting the pool as I discussed earlier.

EDIT: Restart complete. Mine on!

Woot! Nice christmas present

Left you something as well Con. Thanks for making this pool and keep up the good work!

[zOU]

360Ths !!! 

[loshia]

Con,
Would you be so kind to explain what is the story with this commit.

Don't use persistent connections to bitcoind
https://bitbucket.org/ckolivas/ckpool/commits/d2d5a5daaad5d6e2f969d8479b6752ef667e4b06

I never had an issue with presistent connections to BTCD and lo-127.0.0.1. In my understanding it will take longer to reopen tcp on each rpc call or I am missing something.......

Thanks

[-ck]

Con,
Would you be so kind to explain what is the story with this commit.

Don't use persistent connections to bitcoind
https://bitbucket.org/ckolivas/ckpool/commits/d2d5a5daaad5d6e2f969d8479b6752ef667e4b06

I never had an issue with presistent connections to BTCD and lo-127.0.0.1. In my understanding it will take longer to reopen tcp on each rpc call or I am missing something.......

Thanks

Newer bitcoind keeps dropping out during the rpc calls meaning they needed to be reopened and repeated and I needed a workaround - I couldn't find out why it started doing this. In my benchmarking, reopening the connection every time added less than 1ms to rpc calls when the rpc calls themselves take up to 100s of milliseconds but stopped them dropping out in the middle of the rpc calls.

[loshia]

Con,
Would you be so kind to explain what is the story with this commit.

Don't use persistent connections to bitcoind
https://bitbucket.org/ckolivas/ckpool/commits/d2d5a5daaad5d6e2f969d8479b6752ef667e4b06

I never had an issue with presistent connections to BTCD and lo-127.0.0.1. In my understanding it will take longer to reopen tcp on each rpc call or I am missing something.......

Thanks

Newer bitcoind keeps dropping out during the rpc calls meaning they needed to be reopened and repeated and I needed a workaround - I couldn't find out why it started doing this. In my benchmarking, reopening the connection every time added less than 1ms to rpc calls when the rpc calls themselves take up to 100s of milliseconds but stopped them dropping out in the middle of the rpc calls.

Thank you very much that makes sense.
Best