KanoPool since 2014 🐈 - PPLNS and Solo 0.5% fee - Worldwide - 2436 blocks

[porepete]

Goodmorning from Greece, noob alert here, can you tell me if I need to make backups of the wallet.dat file from bitcoin core more than once, I have stored it in multiple usbs, do I need to take backups regurarly after some transactions or just once is enough?

[1714993969]

1714993969

[1714993969]

1714993969

[1714993969]

1714993969

[1714993969]

1714993969

[1714993969]

1714993969

[1714993969]

1714993969

[maddadata]

I vote for a pool re-start.

And what pray tell would you expect that to accomplish?  Besides causing all of us to fail over to our backup pools that is?

Lol. Some superstition that's been floating around for a while that it brings a block. Hehe

P.S. New sig: Kano Pool Blocks... No restart required.

If you look back in history.  Everytime there has been long blocks, and then a "restart" for one reason or another there has been a block found very shortly after, and the near 100 % will continue for a while.

I have seen this numerous times since December that this happens almost like clock work.


YES, saying that it does nothing, becuase of probability, can be an accurate statement, but when this happens too often, there is more to this than just probability.


I dont remember the date, but a while ago, Kano said he needed to do a pool restart due to a logging issue, and then the double restart cuased another issue, and he found why in the code this issue happened.  after that, blocks were normal again, near 100 %  but prior to that there were long blocks.. like now.

Persoanlly, I think there is an issue in some detail yet to be discovered, that after the pool runs for an extended period of time, or so many shares, blocks are not found as near 100% as they should. ( when you use "probability" alone )

Interesting theory...what changes during a mass reboot?  vardiff readjusting for all workers is the one thing I think of, what else?

[ccgllc]

Goodmorning from Greece, noob alert here, can you tell me if I need to make backups of the wallet.dat file from bitcoin core more than once, I have stored it in multiple usbs, do I need to take backups regurarly after some transactions or just once is enough?

Back it up every time after you create a new receiver address.  It those private keys you want to hold onto.  That said, I think most wallets create those in batches, like 100 at a time.

[nazzer]

Not much, but added another S9 today. Going to be interesting when summer really hits here in Texas!   
Current temps are high of 76  on one, and 84 another. Need some more 6 inch duct to bring the 84 down to in the 70's!

Now lets gets some freakin BTCLOCKS BTCABY!!!

Mine run up to 105C , it'll be fine

[kano]

...

Persoanlly, I think there is an issue in some detail yet to be discovered, that after the pool runs for an extended period of time, or so many shares, blocks are not found as near 100% as they should. ( when you use "probability" alone )

Interesting theory...what changes during a mass reboot?  vardiff readjusting for all workers is the one thing I think of, what else?

LOL

Shares (and blocks) are found by miners, not by the pool.

All shares that arrive are first checked/hashed by ckpool, then checked/hashed, from scratch, more accurately by KDB.
That's the only thing that shows if we find a block.

Any share that arrives, and hashes to a value that would produce a block, is displayed by KDB on the web site, no matter what other issues may occur.
(late, orphan, etc etc)

Any suggestion about random events causing blocks is actually caused by faulty memory
It's called 'Confirmation Bias' https://en.wikipedia.org/wiki/Confirmation_bias or in the more severe cases Cognitive Bias https://en.wikipedia.org/wiki/Cognitive_bias

It's typical to remember outstanding events and not notice the rest.

[porepete]

...

Persoanlly, I think there is an issue in some detail yet to be discovered, that after the pool runs for an extended period of time, or so many shares, blocks are not found as near 100% as they should. ( when you use "probability" alone )

Interesting theory...what changes during a mass reboot?  vardiff readjusting for all workers is the one thing I think of, what else?

LOL

Shares (and blocks) are found by miners, not by the pool.

All shares that arrive are first checked/hashed by ckpool, then checked/hashed, from scratch, more accurately by KDB.
That's the only thing that shows if we find a block.

Any share that arrives, and hashes to a value that would produce a block, is displayed by KDB on the web site, no matter what other issues may occur.
(late, orphan, etc etc)

Any suggestion about random events causing blocks is actually caused by faulty memory
It's called 'Confirmation Bias' https://en.wikipedia.org/wiki/Confirmation_bias or in the more severe cases Cognitive Bias https://en.wikipedia.org/wiki/Cognitive_bias

It's typical to remember outstanding events and not notice the rest.

HOW IN THE UNIVERSE DID YOU CREATE A BITCOIN ADDRESS WITH KANO AFTER THE ONE??
I want one with panagiporets after the 1

[Steamtyme]

*snip*

I was waiting fort that response. I'm pretty sure I remember that same post by you in the last few months, probably close to verbatim.

Mine on

[AerialGopher]

so, lets prove me wrong, re-start the pool and lets see what happens! :-)

[VRobb]

<snip>

HOW IN THE UNIVERSE DID YOU CREATE A BITCOIN ADDRESS WITH KANO AFTER THE ONE??
I want one with panagiporets after the 1

Search vanitygen.  Though you might be disappointed in trying to make one as long as you want.

[porepete]

<snip>

HOW IN THE UNIVERSE DID YOU CREATE A BITCOIN ADDRESS WITH KANO AFTER THE ONE??
I want one with panagiporets after the 1

Search vanitygen.  Though you might be disappointed in trying to make one as long as you want.

What if I use my whole name which is Panagiotis Poretsanos?I know what you are thinking, those greeks have huge weird names.

[VRobb]

Search vanitygen and try it.

[DarkStar_]

<snip>

HOW IN THE UNIVERSE DID YOU CREATE A BITCOIN ADDRESS WITH KANO AFTER THE ONE??
I want one with panagiporets after the 1

Search vanitygen.  Though you might be disappointed in trying to make one as long as you want.

What if I use my whole name which is Panagiotis Poretsanos?I know what you are thinking, those greeks have huge weird names.

I don't have a exact answer right now, but on consumer grade hardware, that would take at least a century, and probably longer.

I have 1DarkStrRagcDjWtsPGxkav4WG3poLXzDS which took a few days to find, and the difficulty grows exponentially.

(Sorry for the OT)

[Nick_01]

so, lets prove me wrong, re-start the pool and lets see what happens! :-)

Do you want to say that Kano is not interested in finding blocks by his pool? where is the logic? 

[kano]

so, lets prove me wrong, re-start the pool and lets see what happens! :-)

Do you want to say that Kano is not interested in finding blocks by his pool? where is the logic?  

Indeed - I only restart the pool when it needs to be.
Due to: resource issues, changes, or it restarts itself if it crashes.

Restarting KDB has no effect at all on your work/block finding data unless it cascades into a pool restart also
(which is rare but not 'never')

Yes indeed it is fun to think that restarts are helpful, but when it degenerates in to comments about code problems ... well ... OK ... fun gone

[porepete]

I need my miners to find their first block, to believe that blocks really exist!!!

[AerialGopher]

so, lets prove me wrong, re-start the pool and lets see what happens! :-)

Do you want to say that Kano is not interested in finding blocks by his pool? where is the logic?  

Indeed - I only restart the pool when it needs to be.
Due to: resource issues, changes, or it restarts itself if it crashes.

Restarting KDB has no effect at all on your work/block finding data unless it cascades into a pool restart also
(which is rare but not 'never')

Yes indeed it is fun to think that restarts are helpful, but when it degenerates in to comments about code problems ... well ... OK ... fun gone

I am not doubting your ability's at all.  In fact I know you know what you are doing.  I just made a comment that it has happened a few times that these long spells have been fixed after a pool restart.  Yes, I may notice that moreso than when there was no restart.  

I understand the miners do the work, but the work is issued to them by the pool.  If the work issued or the returned work is not generated properly, or logged properly, or some small thing is happening that is not noticed which yields bad work from miners, or not even that, just missed or mis-handled work of a miner.  Maybe it happens, maybe there is some set of circumstances that occur that is not "visible"  

Look at it this way...  and I know this has happened to me with other stuff.  You write your code, you have gone through it more often than you can remember.  If your looking at it and expecting it to be correct, you might gloss over something.  I do not mean any disrespect by any means.   I have had people look over stuff I have done, and seen something, and its like.. oh yeah... opps.  If there was an issue, i am sure you will find it, or have found other things as you have mentioned.  Maybe the issue is not even with code, it could be something else.  Bad transactions that are put into a block that effect the results, but hard to know which transactions are bad.  And when I say bad, I do not mean one without proper funds, I mean with some other thing someone discovered that can corrupt data etc...


A good example is... remember when android phones could be hacked by just sending it an a particular SMS message.  No one thought that would ever be the case, but somebody found out how to do it.

At the end of the day, Bitcoin has had alot of people doing alot of bad things to gain the advantage.  

So, if I might be noticing these events, lets start a log....  well, actually you probably have a log of re-starts..  look back and find the dates and see if just preceeding it there was low block finds, and then more blocks found just after.  maybe there is another event that happens that causes it, if it is even there.  Maybe there is a set of circumstances that make it happen that isn't discovered yet.

Again, I am not trying to be disrespectful, I know that you are perfect if your work and knowledge.  you understand the inner workings alot better than any of us.  I am just saying it might be worth looking at it from a different angle. ( Again, not code related, but a set of circumstances, internal or external.  Maybe a bad miner like the one you had sending invalid shares for over 2 months that you found. You said that it didnt send one valid share for that 2 or 2+ months, and that it doesnt affect the pool.  So if someone had knowledge to modify miner code to make it send back all invalids, they probably know that this would not harm the pool.  So why are they doing it?  There has to be more to that one. )

[swanny88]

Bitcoin mining is a lot like playing cards for tons of Money.  Sometimes you run good and sometimes you run bad.



I have a feeling we are going to have a couple of 4 block days in the month of May right after we crack this 300 percent block.

[Experimenter]

Yeah the ckpool hash rates are not really a point in time thing ... so relying on them to detect problems isn't highly reliable.

If you have a lot of miners, and don't have any reliable direct miner monitoring software, it's best to look at the workers page once in a while
and then click on the 2 different sortings at the top "Last Share" and "Hash Rate" and see what's at the bottom.

You can also use the "Shift Graph" to see how a single worker is performing over time.

I have successfully used the shift graph to diagnose problems w/my farm.

Using the graphs needs manual check of the web site. I guess there is a way to automate it as well, but it's definitely beyond my bash scripting skills.

I think I will stick with checking the w_lastshare every 5-10 minutes, and will also send myself the hashrate stats once or twice a day. This should be good enough for my needs. In case of any issues, further investigations will be done manually anyway (that's when I will check the pool website, miner pages, etc.)

Thanks!


BTW, is there a way to calculate the difficulty of the last block found by the pool based on the data provided by the API?

[kano]

Yeah the ckpool hash rates are not really a point in time thing ... so relying on them to detect problems isn't highly reliable.

If you have a lot of miners, and don't have any reliable direct miner monitoring software, it's best to look at the workers page once in a while
and then click on the 2 different sortings at the top "Last Share" and "Hash Rate" and see what's at the bottom.

You can also use the "Shift Graph" to see how a single worker is performing over time.

I have successfully used the shift graph to diagnose problems w/my farm.

Using the graphs needs manual check of the web site. I guess there is a way to automate it as well, but it's definitely beyond my bash scripting skills.

I think I will stick with checking the w_lastshare every 5-10 minutes, and will also send myself the hashrate stats once or twice a day. This should be good enough for my needs. In case of any issues, further investigations will be done manually anyway (that's when I will check the pool website, miner pages, etc.)

Thanks!


BTW, is there a way to calculate the difficulty of the last block found by the pool based on the data provided by the API?

No, the API's aim is to provide current data - it does name the last pool and network block, but to be able to calculate other current information since either of those.
The web site shows history.

[Shazam!!!]

These long blocks certainly put a strain on people!!! C'mon BTClock!!! Ha!!!