kano (OP)
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 08, 2015, 05:25:07 AM |
|
... and that record 17 blocks from #7 to #23 all under 100% Diff with an average of ... 29.9% Diff
|
|
|
|
xZork
|
|
October 08, 2015, 05:40:44 AM |
|
... 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 (OP)
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 08, 2015, 05:56:37 AM |
|
... 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
Legendary
Offline
Activity: 1302
Merit: 1068
|
|
October 08, 2015, 06:06:39 AM |
|
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
|
|
October 08, 2015, 01:05:55 PM |
|
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!
|
BTC: 1Bo6YsPeHCrVRygHLJg9BwHeaLSQpppcJi "Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone."
|
|
|
PPOC
|
|
October 08, 2015, 01:12:04 PM |
|
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,
|
BTC: 1Bo6YsPeHCrVRygHLJg9BwHeaLSQpppcJi "Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone."
|
|
|
basv123
Newbie
Offline
Activity: 49
Merit: 0
|
|
October 08, 2015, 05:43:32 PM |
|
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
|
|
October 08, 2015, 06:34:28 PM |
|
ok
Thanks,
Can you remove this suggestion and PM it to kano? maybe it is information vailuable for CKpool!?!
|
BTC: 1Bo6YsPeHCrVRygHLJg9BwHeaLSQpppcJi "Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone."
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
October 08, 2015, 07:19:50 PM |
|
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
Member
Offline
Activity: 90
Merit: 10
|
|
October 08, 2015, 07:30:50 PM |
|
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 (OP)
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 08, 2015, 10:23:36 PM |
|
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
|
|
October 08, 2015, 10:33:05 PM |
|
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.
|
BTC: 1Bo6YsPeHCrVRygHLJg9BwHeaLSQpppcJi "Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone."
|
|
|
kano (OP)
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 11, 2015, 07:09:40 AM |
|
Oh well, seems it was our turn for another 'Unworthy' share close to being a block, but not quite good enough. [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
|
|
October 11, 2015, 07:27:13 AM |
|
We will get a quick pop now
|
Transaction fees go to the pools and the pools decide to pay them to the miners. Anything else, including off-chain solutions are stealing and not the way Bitcoin was intended to function. Make the block size set by the pool. Pool = miners and they get the choice.
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
|
October 11, 2015, 07:30:28 AM |
|
Oh well, seems it was our turn for another 'Unworthy' share close to being a block, but not quite good enough. [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 [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
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
SergES
Member
Offline
Activity: 81
Merit: 10
|
|
October 11, 2015, 07:44:30 AM |
|
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
|
|
October 11, 2015, 09:02:24 AM |
|
Oh well, seems it was our turn for another 'Unworthy' share close to being a block, but not quite good enough. [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 [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
|
Transaction fees go to the pools and the pools decide to pay them to the miners. Anything else, including off-chain solutions are stealing and not the way Bitcoin was intended to function. Make the block size set by the pool. Pool = miners and they get the choice.
|
|
|
basv123
Newbie
Offline
Activity: 49
Merit: 0
|
|
October 11, 2015, 11:23:33 AM |
|
Another 80 hours?
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 11, 2015, 12:49:42 PM |
|
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
Newbie
Offline
Activity: 49
Merit: 0
|
|
October 11, 2015, 01:11:38 PM |
|
so the previous block was an orphan or what?
|
|
|
|
|