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

[kano]

... and that record 17 blocks from #7 to #23 all under 100% Diff with an average of ... 29.9% Diff

[xZork]

... and that record 17 blocks from #7 to #23 all under 100% Diff with an average of ... 29.9% Diff

Wish I as mining here then! We should do that again some time :p

[kano]

... and that record 17 blocks from #7 to #23 all under 100% Diff with an average of ... 29.9% Diff

Wish I as mining here then! We should do that again some time :p

Ah well there was 14 in a row under 101% from #268 to #281 with an average of 45.9% Diff that wasn't too shabby

Though that good run ended with our worst record 666.666% Diff block ...

[VirosaGITS]

Oh wow, a 0.8% block, is that a record for this pool?

Someone show me the odds of the same miner solving two blocks in such quick succession, that's simply amazing.

See, it must have been all that talk about chickens and restarts that did it!  

We've had 4 under 1%
That one is the 3rd best.

I switched the block limit shown on the blocks page - you can currently see all history

Very nice! I notice the second block of all time was orphan xD Bad odds, some people must of feared for the orphan rate by getting one so soon?

And wow double block, maybe thedreamer's voodoo really work, but its just him asking that cause the shift in reality to get us blocks?

[PPOC]

Oh wow, a 0.8% block, is that a record for this pool?

Someone show me the odds of the same miner solving two blocks in such quick succession, that's simply amazing.

See, it must have been all that talk about chickens and restarts that did it!  

We've had 4 under 1%
That one is the 3rd best.

I switched the block limit shown on the blocks page - you can currently see all history

Excellent, thank you. Always wanted to see the stats on all the blocks for the pool!

[PPOC]

Kind of a general questions for Kano on block finds, been thinking about it for a while. Not just at this pool, but looking at the block chain and other pool stats, It seams that quite often you see the same pool find blocks in a row, pretty quickly in most cases. My assumption was that if your pool & miner find a block, then your pool is the first one to switch mining the next block. Especially if you have good code and very fast servers. I would think it takes a few seconds for all the other pools to move to the next block and thus would seam IF that next block is to be a low diff block (luck) you would get it before others since you were the first to switch to mining the next bock. At least a few seconds before others.

Am I all wrong here, or its just dumb luck and no advantage like I see there might be.

Thanks,

[basv123]

Kind of a general questions for Kano on block finds, been thinking about it for a while. Not just at this pool, but looking at the block chain and other pool stats, It seams that quite often you see the same pool find blocks in a row, pretty quickly in most cases. My assumption was that if your pool & miner find a block, then your pool is the first one to switch mining the next block. Especially if you have good code and very fast servers. I would think it takes a few seconds for all the other pools to move to the next block and thus would seam IF that next block is to be a low diff block (luck) you would get it before others since you were the first to switch to mining the next bock. At least a few seconds before others.

Am I all wrong here, or its just dumb luck and no advantage like I see there might be.

Thanks,

Can you remove this suggestion and PM it to kano?

maybe it is information vailuable for CKpool!?!

[PPOC]

ok

Thanks,

Can you remove this suggestion and PM it to kano?

maybe it is information vailuable for CKpool!?!

[Mikestang]

Kind of a general questions for Kano on block finds, been thinking about it for a while. Not just at this pool, but looking at the block chain and other pool stats, It seams that quite often you see the same pool find blocks in a row, pretty quickly in most cases. My assumption was that if your pool & miner find a block, then your pool is the first one to switch mining the next block. Especially if you have good code and very fast servers. I would think it takes a few seconds for all the other pools to move to the next block and thus would seam IF that next block is to be a low diff block (luck) you would get it before others since you were the first to switch to mining the next bock. At least a few seconds before others.

Am I all wrong here, or its just dumb luck and no advantage like I see there might be.

Thanks,

A general answer to your general question, pools that are coded to optimize block changes and get new work faster have better chances of having their solved blocks confirmed and not become an orphan.

[PCComf]

ok

Thanks,

Can you remove this suggestion and PM it to kano?

maybe it is information vailuable for CKpool!?!

I believe it is already pretty known. It is one of the better and more reasonable arguments against increasing the block size too much that I've heard, in my opinion anyway. As blocks get bigger, the propagation time would also increase and amplify the effect you describe. It puts pools on slower connections or with inferior software/hardware at a greater disadvantage. Or, even the opposite, for example, a large pool or set of pools in China could build blocks off themselves or each other faster than they could propagate it elsewhere.

[kano]

Heh I replied last night but as is often the case, the forum timed out.
The post didn't arrive and I didn't check it did

Anyway, regarding ckpool/kano.is, our block handling is very fast and our network connectivity is excellent.
I can't really see a 'reasonable' block size increase causing much detriment for us.
I can see it causing problems for other pools ...

By reasonable, I mean megabytes, not gigabytes ...

Block switching, for any good pool, is a quick thing and being only a few seconds makes very little difference to the chances of finding the next block.
A pool with 15% of the network is expected on average to find one block every 4000 seconds, so even a large 4s extra is a small 1 in a 1000.

However, if there was a cartel of pools, then that cartel has the same risk of destroying BTC if they had 51% of the network, as a single pool with 51% would have.
If a group of pools was stupid enough to do such a thing ... then ... well they can say goodbye to their pool like everyone else.
Who know if they think ahead or not ... though the fact that pools SPV mine and mine empty blocks shows that certain pool operators don't care how long bitcoin lasts and would be better gone from the bitcoin landscape.

-

Payouts 377918 and 377920 sent
09d038ee8a868b97b899e268af6cb127108f46af4c705118fbbea13abc7a6d1c
40e5283e9ad6b4c82680ce5d42eff0788bbdfc404ad3b325515aa14505a025be
and confirmed 20 minutes ago

[PPOC]

Heh I replied last night but as is often the case, the forum timed out.
The post didn't arrive and I didn't check it did

Anyway, regarding ckpool/kano.is, our block handling is very fast and our network connectivity is excellent.
I can't really see a 'reasonable' block size increase causing much detriment for us.
I can see it causing problems for other pools ...

By reasonable, I mean megabytes, not gigabytes ...

Block switching, for any good pool, is a quick thing and being only a few seconds makes very little difference to the chances of finding the next block.
A pool with 15% of the network is expected on average to find one block every 4000 seconds, so even a large 4s extra is a small 1 in a 1000.

However, if there was a cartel of pools, then that cartel has the same risk of destroying BTC if they had 51% of the network, as a single pool with 51% would have.
If a group of pools was stupid enough to do such a thing ... then ... well they can say goodbye to their pool like everyone else.
Who know if they think ahead or not ... though the fact that pools SPV mine and mine empty blocks shows that certain pool operators don't care how long bitcoin lasts and would be better gone from the bitcoin landscape.

-

Payouts 377918 and 377920 sent
09d038ee8a868b97b899e268af6cb127108f46af4c705118fbbea13abc7a6d1c
40e5283e9ad6b4c82680ce5d42eff0788bbdfc404ad3b325515aa14505a025be
and confirmed 20 minutes ago

Thanks for the response, I kind of figured that also, but what made me consider this is a pool that has say 100Ph, and for them SOMETIMES blocks hit with VERY low diff and at 100Ph, even a few seconds makes a difference. So if they hit the last one, then switch to next one at 100Ph, they can find another block and maybe another within seconds. Pretty much before other pools have switched to the next block. When you looks at the history of some of these large pools, its 2,3,4 in a row and sometimes seconds apart. Anyway, thats what made me think of this scenario.

Now imagine what damage we could be with your code, top of the line servers, flash storage and backbone fiber links and 100PH.....Unstoppable

Kind of like high frequency stock trading with servers across the hall from NADAQ servers but in the mining space.

[kano]

Oh well, seems it was our turn for another 'Unworthy' share close to being a block, but not quite good enough.

Code:

[2015-10-11 17:59:36.026] Possible block solve diff 60236096986.205208 !
[2015-10-11 17:59:36.051] SUBMIT BLOCK RETURNED: high-hash

Current diff is (of course) 60813224039.44034576
Close but no block

[sloopy]

We will get a quick pop now 

[-ck]

Oh well, seems it was our turn for another 'Unworthy' share close to being a block, but not quite good enough.

Code:

[2015-10-11 17:59:36.026] Possible block solve diff 60236096986.205208 !
[2015-10-11 17:59:36.051] SUBMIT BLOCK RETURNED: high-hash

Current diff is (of course) 60813224039.44034576
Close but no block

Must have been the day for near misses dammit with one so similar on solo it's scary

Code:

[2015-10-10 11:57:29.076] Possible block solve diff 60343501782.267929 !
[2015-10-10 11:57:29.141] SUBMIT BLOCK RETURNED: high-hash
[2015-10-10 11:57:29.141] Submitted, but rejected block 378262

[SergES]

378389   bitminerpro_S4.78A504B8AF0F   25.01764342   2015-10-11 06:59:36+00   ?     Unworthy   *129,706,365,253   213.286%   0.882   0
45 min
deplorably

[sloopy]

Oh well, seems it was our turn for another 'Unworthy' share close to being a block, but not quite good enough.

Code:

[2015-10-11 17:59:36.026] Possible block solve diff 60236096986.205208 !
[2015-10-11 17:59:36.051] SUBMIT BLOCK RETURNED: high-hash

Current diff is (of course) 60813224039.44034576
Close but no block

Must have been the day for near misses dammit with one so similar on solo it's scary

Code:

[2015-10-10 11:57:29.076] Possible block solve diff 60343501782.267929 !
[2015-10-10 11:57:29.141] SUBMIT BLOCK RETURNED: high-hash
[2015-10-10 11:57:29.141] Submitted, but rejected block 378262

Whoah. that is insane.
I would say what are the odds, but, someone will calculate them

[basv123]

Another 80 hours?

[kano]

Another 80 hours?

At any particular point in time, no matter when the last block was found or how many blocks a pool has found, a pool is expected to find a block 100% Diff from 'now'

So at 1.8PHs that's ~40hrs.
We may find it sooner, or we may find it later, but that's simply the expected time at 1.8PHs

If an hour passes, independent of it we find 0, 1 or 20 blocks in the next hour, the next block will be expected ~40hrs after that.

[basv123]

so the previous block was an orphan or what?