Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 232. (Read 5352633 times)

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.

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?

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.

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. )

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

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

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

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)

Search vanitygen and try it.

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

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

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

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

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

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.

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

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.

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

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?

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 )