Looks like it was a lucky restart 28.5% diff  [2018-06-14 02:48:52.301] Possible block solve diff 13407697225685.988281 !
[2018-06-14 02:48:52.322] BLOCK ACCEPTED!
[2018-06-14 02:48:52.331] Solved block 527356 by 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0
[2018-06-14 02:48:52.332] User 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V:{"hashrate1m": "109P", "hashrate5m": "109P", "hashrate1hr": "90.8P", "hashrate1d": "54.1P", "hashrate7d": "51P"}
[2018-06-14 02:48:52.332] Worker 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0:{"hashrate1m": "96.9P", "hashrate5m": "97.8P", "hashrate1hr": "82.2P", "hashrate1d": "52.6P", "hashrate7d": "50.6P"}
[2018-06-14 02:52:06.690] Hash for block height 527356 confirms block was CONFIRMED
Full payout details: http://ckpool.org/blocks/527356.confirmed |
|
|
|
|
Pool restarted with code changes as you can see in the public git, to address the wrong hashrate of our ultra-big miner. Start difficulty has been changed to 10k to reflect new generation miners better. Downtime was negligible. Mine on, and let's get some lucky ones!
|
|
|
|
CK what was the highest PH rate we hit in the last month. It was pretty high.
215 |
|
|
|
Last block details: [2018-06-13 13:28:53.760] Possible block solve diff 5705566207315.975586 !
[2018-06-13 13:28:53.831] BLOCK ACCEPTED!
[2018-06-13 13:28:54.171] Solved block 527282 by 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0
[2018-06-13 13:28:54.237] User 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V:{"hashrate1m": "51.2P", "hashrate5m": "51.3P", "hashrate1hr": "51.2P", "hashrate1d": "52P", "hashrate7d": "50.5P"}
[2018-06-13 13:28:54.238] Worker 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0:{"hashrate1m": "49.8P", "hashrate5m": "49.9P", "hashrate1hr": "49.9P", "hashrate1d": "51.5P", "hashrate7d": "50.4P"}
[2018-06-13 13:32:15.303] Hash for block height 527282 confirms block was CONFIRMED
Gotta break this bad luck streak sooner or later. I will be restarting the pool later today for some minor fixes. |
|
|
|
Ya, well clearly Kano has other issues beyond 'getting time to debug that crappy code'.. Funny how ck, slush, bitminter, and f2pool seemed to implement the required changes fairly easily without any sort of anger management issues..
Most of his problem is he has great issues with the developer who's maintaining the driver and ckpool and having to look at such code instantly gives him hives, rising blood pressure, bile in the back of the throat and skyrocketing blood sugars from the stress response. The cgminer driver code is, however, mostly Halong's and I spent more time debugging the crap out of it and cleaning it up since it was barely working originally. Add to that the refusal to ever use my code if he has a choice any more means there's no way he'll just accept the changes straight into ckpool from the master ckpool git (which already has version rolling support) since he wouldn't trust me to code a hello world because obviously my code is disastrously bad. The actual commits required to get version rolling support in ckpool are actually quite small and well contained, but he feels obliged to do it from scratch, and get to complain bitterly about me directly and indirectly in the process, but that's his prerogative. |
|
|
|
is there a stratum that more then 4k diff and less than 1m diff? Ck
No, afraid not. |
|
|
|
Hi,
did anyone solved the problem cgminer crashes the Raspberry Pi? (Raspbian)
After putting slub_debug=FP into /boot/config.txt systenm holds for about 8-24 hours then crashes on kernel paging:
Jun 8 12:00:20 RPinode kernel: [50708.328638] Unable to handle kernel paging request at virtual address 223fab15
I could find many other people having the same but no definitive fix or workaround
It's a linux kernel crash; i.e. an operating system crash. No userspace program should be able to do that so it's not cgminer at fault. Thanks, but I was trying bfgminer and it works so they maybe did some workaround They don't use direct USB drivers. No, I'm not rewriting anything... |
|
|
|
So, oddly enough--or maybe not because I stopped watching the water boil (chicken or beef, take your pick  )--I've found myself nearly at the threshold of the Top 10 Postponed users. (BTW congrats on the exponential growth since I've started failing over here) Preface: Let's say after this block, I'm then included in those slated to get a reward next time. Question: What change should I expect to take place to my HERP/DERP after the next block? Do one/both drop to zero and everything resets? Just curious. Thanks! If your hashrate and the pool hashrate is the same and you've been here for 5N, then your herp derp remains the same and you get the same payout each block if you're in the top 100. If not in the top 100, your herp remains the same and again your derp keeps rising till above the threshold and in the top 150 again. |
|
|
|
Yum, not the thread I was expecting here today.
My thread, I can allow the discussion to go wherever I like  High protein, high fat everyday.
We have a local farmer's market where the beef farmer we buy our beef from usually responds to our request for a fatty cut with "people who don't eat fat don't smile." |
|
|
|
Block PARTY!!??!!
That party is over. That was three hours ago. "What have you done for me lately". We need steak guy and beer guy to do their thing to start a new party. I had a roasted chicken today. Yeah I know wrong pool. Next meal will be roasted ribs of lamb. Really good taste just started this type of meal this year. Roasting food is the most underrated method of making a great meal. Sure it takes time, but it takes almost no effort, and ends up being a fine meal. Might bring a red along as accompaniment for this block party then. |
|
|
|
Here are the last block's details: [2018-06-11 14:13:35.663] Possible block solve diff 8820053486394.513672 !
[2018-06-11 14:13:35.794] BLOCK ACCEPTED!
[2018-06-11 14:13:36.328] Solved block 526993 by 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0
[2018-06-11 14:13:36.504] User 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V:{"hashrate1m": "53.3P", "hashrate5m": "53.3P", "hashrate1hr": "52.9P", "hashrate1d": "50.5P", "hashrate7d": "48.1P"}
[2018-06-11 14:13:36.504] Worker 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0:{"hashrate1m": "53.3P", "hashrate5m": "53.3P", "hashrate1hr": "52.9P", "hashrate1d": "50.5P", "hashrate7d": "48.1P"}
[2018-06-11 14:25:01.076] Hash for block height 526993 confirms block was CONFIRMED
A decent number of transaction fees in that block pushed it to 13BTC as others have noted. Mine on. |
|
|
|
I couldn't agree with this more!!! To add salt to the wound, this "unofficial" thread started in the speculation board. Halongmining
has never even bothered to create a new thread, in support of their own product.
Myrig created a support thread. No one used it: https://bitcointalk.org/index.php?topic=3731220.0 |
|
|
|
I disagree, PPLNS is the problem...I can't accept that there are NOT other better methods which can protect the operator AND greatly reduce the risk to miners. Irrespective of pool size.
I SHOULD HAVE made a more polite and elegant argument and appeal to consider changing to a PPS system.
I for one would be happy to pay 4/5% to CK to code and operate a pool to aid in decentralization
I would stay and pay an even higher % if the fee was variable and linked proportionally to pool luck and Hash rate.
8 years of pooled mining and input from many maths geniuses has failed to find a "better way" than PPLNS - the stochastic nature of block finding is the actual issue. Even if I charged 10% fee and ran PPS the pool would have gone bankrupt by now. A different cryptocurrency with a deterministic block finding would be so much easier, but so much more game'able. |
|
|
|
If Halong continues this pool is more of a Halong pool as opposed to a collection of decentralized miners.
It may be a "Halong pool" because most of the hashrate is from Halong but it's not a Halong pool in reality because I'm the one choosing the transactions and work to include, and I use default bitcoin core daemon rules. In that regard, it's totally different to bitmain miners being owned by bitmain mining at a pool run by bitmain. |
|
|
|
We are obviously not celebrating per se but we're trying hard to remain optimistic. Your anger is misguided. Presumably the catalyst for your outbreak was the latest fall in bitcoin value and you've finally had enough of mining at this small pool. Anyone who mines at a small pool should be well aware of the risks of bad luck from mining there. It's always going to be a gamble and unfortunately we've been hit by a string of relatively bad luck - but that can change at any time, for better or worse. What is the point of your outburst apart from telling us why you are leaving? Do you see it as a public service to prevent other people from losing their money by mining here? Do you think I run this pool out of malice to make miners intentionally lose money? Your anger and frustration has been duly noted, but there is absolutely nothing we can do about it, and you are worsening the situation by making more people try and move away. This is precisely why it is so hard for a small or new pool to get off the ground, why decentralisation is increasingly difficult, and why people continue to flock to larger pools - because of the lesser variance the large pools provide, and in so doing further worsen the centralisation situation. |
|
|
|
What is the mining pool sentiment of replacing stratum with this 'BetterHash' proposal by Matt Corallo?
If I understand it correctly, it will decouple pool selection and block construction.
I haven't chimed in on this publicly because I think people would be disappointed by my response and criticise me for being negative. It's a great idea, but will be a complete failure in the real world I'm afraid. Even if I write the reference client and server software to use the protocol, no mining hardware out there and virtually no pool will be using it, thanks to Bitmain's hardware and pool dominance. I've had this discussion with Matt but he's more hopeful than me; otherwise he wouldn't have gone to the effort of formalising his proposal. I'd be happy to be proven wrong on this... All the news stories I've read are glowingly positive that this is a good idea, which I agree it is. However, nobody bothered to ask a miner/ pool operator. And therein lies the problem... Since I wrote the reference mining software and many drivers, and wrote pool software and have administrated on 4 pools over the years... I'm a realist. |
|
|
|
Well we need blocks. So I just put some steaks on the grill. Should be soon for the block party  I'll bring some beers. No shrimp? Good idea. |
|
|
|
What is the mining pool sentiment of replacing stratum with this 'BetterHash' proposal by Matt Corallo?
If I understand it correctly, it will decouple pool selection and block construction.
I haven't chimed in on this publicly because I think people would be disappointed by my response and criticise me for being negative. It's a great idea, but will be a complete failure in the real world I'm afraid. Even if I write the reference client and server software to use the protocol, no mining hardware out there and virtually no pool will be using it, thanks to Bitmain's hardware and pool dominance. I've had this discussion with Matt but he's more hopeful than me; otherwise he wouldn't have gone to the effort of formalising his proposal. I'd be happy to be proven wrong on this... |
|
|
|
Well we need blocks. So I just put some steaks on the grill. Should be soon for the block party I'll bring some beers. |
|
|
|
|
Show Posts
