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

my sp20 miner has this options in settings:

1:no-scaling 2:extranonce.subscribe 4:no-debug 8:alt-bistword

i d like to know if i must include some of that options for CKpool.

Thanks, and continue to use the unabridged version of useful knowledge.

Ahh. I was wondering why my username never showed up there. LOL

Payout 346912 (finally) sent
725676dfd3128f568f0dcee2d74addc5caa9b2bce4871506ff637b7e48c940d8
and confirmed about 50 minutes ago.

Regarding shifts:
I'll write a long complicated description coz ... well ... not sure how else to describe it

Currently the pool gets about 50 million shares a day
Obviously you can't store each share individually anywhere useful - too much data.
So instead the data is summarised.

These are the shifts.

OK now a long version:
ckpool itself gives out work to miners based on a template from bitcoind
We call this a workinfo (that has a unique workinfoid)
ckpool gets a new one every 30 seconds and also every time a new block is found on the network.

The shares ckdb gets from ckpool, it groups them under the workinfoid per worker - called a sharesummary
So that firstly means that the number of sharesummaries a day is ~2880 * workers

These are like mini-shifts ~30 seconds long.

Next ckdb groups every ~100 sharesummaries together into a markersummary (that has a range of workinfoid's defined in a workmarker)
It's not always 100, since it has to stop whenever the pool finds a block and it stops at the point if ckpool restarts.
So now we are down to about ~29 * workers markersummaries a day that are also stored in permanent DB storage.

These are shifts ~50 minutes long.

Workmarkers are defined by 2 consecutive marks that specify a workinfoid range.
These marks are the shift end points as shown on the Shifts page.
A workmarker range is the first workinfoid after the previous shift mark to the end of the current shift mark.
The unique names for shifts include a name at the end to ensure they are unique.
They only had to be a letter, but for fun I decided to give each letter a female anime character name

When a payout is generated, it has to count back shares from the block until it reaches or exceeds the payout limit (at the moment 500%)
It can't stop at exactly the limit since the shares aren't individually stored.
It must stop at the start of a workmarker i.e. the start of a shift, and include all shares in the shift, since that's the only point to stop that's fair to all workers.
This, of course, is due to the fact that a shift has shares ranging over the 50 minutes of the workmarker range, so if one markersummary for a given workmarker is included, all markersummaries for the given workmarker have to be included.

Yeah... I've had my 6 S3s pointed here for a while (I've still got 2 on p2pool).  If I had the 8 of them here, I'd be a bit higher up the list .

As far as shifts, that shows you how you've been doing for each of the shifts.  We keep talking about PPLNS being about the last N shares - which it is - but Kano (and BTC Guild, and GHash and others) also use the concept of shifts as well.  In a nutshell, they're used to simplify the amount of data crunching necessary.  I'll let Kano explain in more detail about how the shifts are utilized to determine payouts here.

Hey! I was soo close!! (Lol I'm right on top of your name on the stats list).

Also, what is the -> for? What does it show?

347038 looks to be staying here...

The block share count restarts.
Everything else counts it as if there was no block - i.e. there'll be no payout and (soon) the rewards will disappear.
The new block stats (that I'm working on) also treat it correctly that way - as does the total at the bottom of the current blocks web page.
Edit: of course the actual shares count everywhere as if they are part of the next block that will be found - but that doesn't show that way on the blocks page since it shows the actual orphan separately.

My question is what happens to the share count on a orphan block? Is the count thrown out and restarts over or are they still counted?

On blockchain you are looking at unreliable information that they put up and pretend it is reliable.
"first relayed" by is the IP address that blockchain got it from.

Remember, blockchain is nothing more than another node on the bitcoin network.
Blocks and transactions get passed around the network, one after the other as they spread around the world.
Most people are not connected to blockchain, so blockchain gets most of their information 2nd, 3rd, 4th ... etc... hand.

There was about 50 minutes between the next block and apparent orphan does that necessarily mean that one pool/miner found it first, or that it was recorder by a node that block in question was solved by another an then the other miner was the right order. Are there any time stamps involved, I would guess no? Also, I know I am getting way off here... but, what does "first relayed by" mean exactly?

Sorry for getting a bit off topic :/

FYI

After our last orphan this pool went on a BLOCK rampage.

If I remember we had +1% of network of blocks found with much less hash rate.

It appears that Blockchain and Blocktrail both are not reporting an orphan at that height yet.

The payout information still needs correcting (will be done later)
I'll need to manually correct that (flag/remove it) since it shows the numbers but that payout of course wont happen.
The code that flags an orphan has yet to do the reward adjustments.
Also, the code that automatically detects the orphan didn't actually work - since the block was still in bitcoind but just as an orphan.
Will also need to fix that in the ckdb code.

BUMMER  

I remember the 1st ORPHAN!  nothing was worse than the second block we ever found was a orphan.
I got over it (kind of) and just kept on hashing.
by my figurers it cost about 7BTC.
It's still the best pool you can point all your miners at.  

I assume we don't get paid for orphans (and now clearly marked as such under bocks) ..... but still showing value under rewards!

It's a misnomer.
It's a block with no children in the main chain.
and it's parent has disowned it, not died

Basically, when 2 pools/people find a block at the same time, they are distributed around the internet.
Each bitcoind that receives them in the order they get them, decides either:
1) I've not seen any block at this height before. OK, I decide this is the next OK block
2) I've already seen a block at this height before, so you aren't the winner (but I'll hang on to you just in case that changes later)
The next network block will do the same thing and usually decide the winner as long as an orphan race doesn't happen with that block and thus repeat the process.

Whoever stole that block also solved 346914.  Quick 50BTC.


An orphan is a block that loses the race to be accepted by the majority.  It happens when 2 miners submit a block solution at or near the same time.  Both get added to the chain.  Eventually one wins the race.  It stays on the chain.  The loser becomes the orphan.

Come on now. Little orphan Annie? Nothing?

A block that does not get confirmed is an orphaned block and thus not paid.

Poor little orphans, someone should find them a wallet to call home.   

So what's an orphan anyways?