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

[kano]

Well, I will add what some may see as an unexpected follow up comment.

This does actually mean we should expect to see fewer orphans.
The times shown on the non-GFW relays were quite a long time after the GFW relay (bjs)
So it does mean our blocks do get into the GFW faster.

... Just it didn't help for this orphan due to the short timing.
Without the CN node, this still would have happened the same, and not having the GFW relay info would have had me ranting even more about it, since the non-GFW relay numbers are shocking to say the least ... FUPool block 4-7 seconds after ours.

[citronick]

Huh.... rubbing my eyes.... waking up to RED dashboard this morning.... 2 orphans.... Fish...

DEFCON1 !!!!!

I am sure kano and ck have something up their sleeves to counter this.... I want to elaborate further but I am sure the mac guy can see our posts.....

I leave it to the good hands of kano and ck --- they are probably midway crafting the next move.... 1, 2, 3, 4, 5, 6, 7.....

[VRobb]

I agree with the argument that pools shouldn't exceed 10% of the network. But in situations like this, the argument can be made that a large pool outside of cn is needed.

Most heartily fucking agree, and THIS is one of the pools that should do it IMHO.  Though I will always defer to the opinions and decisions that -ck and kano-san deem appropriate.  It's their pool after all, and as with anything in life, "love it, or leave it!"

Our benevolent dictators, huzzah!

[HerbPean]

So basically the cause was one or more of the following:
FUPool works on their own blocks after they see other pool blocks if they are found soon after.

Wow, I would call this an exploit. It would gave them the ability to mine until the next block is found by the network praying they will get the next one to screw the orphan race they lost for the previous one.

I hope this is not the case

EDIT: Indeed the bigger you are, the chance you have to been able to use the "exploit" increase greatly.

[philipma1957]

So basically the cause was one or more of the following:
FUPool works on their own blocks after they see other pool blocks if they are found soon after.

Wow, I would call this an exploit. It would gave them the ability to mine until the next block is found by the network praying they will get the next one to screw the orphan race they lost for the previous one.

I hope this is not the case

that's the one that is truly gaming the system.  not sure they did it but if it were to happen over and over and over it is flat out wrong.

[usukan]

I am thinking that this orphan issue is just the tip of the iceberg - beyond this we have our extraordinary bad luck for many days now.

I suspect something has changed and this pool is getting locked out of blocks somehow.  The orphans may/may not be related.

This is exactly what happened at Slush before I moved here.  I'm having a deja vu.

[macbook-air]

So ... ... fuck, crap, &#$^*# *(#$&*(&$(* (*#&$(* &#*(&$ #( (*#&*( $&(*#, someone find something I can kill ... ... ... ...

OK, now for the details.

The CN node did indeed do it's work properly.
But that still wasn't good enough.

Every single relay shows our block before the f2pool block, even the CN relay.
Every single relay shows our block sent back to us before the f2pool block, even the CN relay.
... the us relays don't show us sending it to the relay coz the solo pool did that faster.

Our time to process the block was 280ms.

I've shortened all the block hashes below to 4 zeros and 4 hex since that's enough to see which is which.

00003e80 is 410418 BTCC in china - all pools worked on this block

*00002b07* is 410419 our block

-00001f67- is 410419 FUPool
00003007 is 410420 FUPool confirming their block

Code:

bjs [2016-05-05 23:35:17.374+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
bjs [2016-05-05 23:38:01.073+00] *00002b07* sent, size 985717 with 37638 bytes on the wire
bjs [2016-05-05 23:38:01.209+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
bjs [2016-05-05 23:38:02.227+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
bjs [2016-05-05 23:44:40.138+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

jpy [2016-05-05 23:35:17.561+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
jpy [2016-05-05 23:38:01.122+00] *00002b07* sent, size 985717 with 37638 bytes on the wire
jpy [2016-05-05 23:38:01.291+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
jpy [2016-05-05 23:38:08.164+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
jpy [2016-05-05 23:44:40.200+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

eu [2016-05-05 23:35:17.641+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
eu [2016-05-05 23:38:01.118+00] *00002b07* sent, size 985717 with 37638 bytes on the wire
eu [2016-05-05 23:38:01.163+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
eu [2016-05-05 23:38:05.960+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
eu [2016-05-05 23:44:40.240+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

us-east [2016-05-05 23:35:17.741+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
us-east [2016-05-05 23:38:01.601+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
us-east [2016-05-05 23:38:08.310+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
us-east [2016-05-05 23:44:40.268+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

us-west [2016-05-05 23:35:17.741+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
us-west [2016-05-05 23:38:01.601+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
us-west [2016-05-05 23:38:08.310+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
us-west [2016-05-05 23:44:40.268+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

The winner was of course decided by the next block (00003007), but the problem is: why was FUPool not working on our block?

So basically the cause was one or more of the following:
FUPool is REAL slow getting their blocks to the CN relay.
FUPool works on their own blocks after they see other pool blocks if they are found soon after.
FUPool had most of their 410419 block transactions not in the relay so was really slow getting their block into the relay (compression was almost zero as you can see) Edit: but I don't think this is it coz it was prolly the relay did that coz it already had our block using the transactions.

Until you spell our name correctly, you won't be able to understand why you always get orphaned. We haven't have any orphans for 7 weeks, or more than 1400 blocks.

[philipma1957]

I am thinking that this orphan issue is just the tip of the iceberg - beyond this we have our extraordinary bad luck for many days now.

I suspect something has changed and this pool is getting locked out of blocks somehow.  The orphans may/may not be related.

This is exactly what happened at Slush before I moved here.  I'm having a deja vu.

did not want to say this but I did think it.


what is worse is this if this is true it   confirms it:

...


Until you spell our name correctly, you won't be able to understand why you always get orphaned. We haven't have any orphans for 7 weeks, or more than 1400 blocks.

Now take a step back and look at this the leader of the largest pool said this.

  Forget everything about kano.is

 think overall what the claim is :     we can crush you  or orphan you   or waste you   ..


I know of a few ways they can do it.   

so to everyone here that is renting  from NH / WH   consider that

   f2pool can send dead hashers to   WH/NH  with ease   
   f2pool can mine on is own blocks  out of proper order.  they actually did this and caused a fork.
   f2pool  claims they   can always orphan us see above.

[Sierra8561]

I am thinking that this orphan issue is just the tip of the iceberg - beyond this we have our extraordinary bad luck for many days now.

I suspect something has changed and this pool is getting locked out of blocks somehow.  The orphans may/may not be related.

This is exactly what happened at Slush before I moved here.  I'm having a deja vu.

did not want to say this but I did think it.


what is worse is this if this is true it   confirms it:

...


Until you spell our name correctly, you won't be able to understand why you always get orphaned. We haven't have any orphans for 7 weeks, or more than 1400 blocks.

Interesting wonder what kano thoughts are. I did notice slush's pool is killing blocks lately. Rigging the system seems difficult.

[macbook-air]

So ... ... fuck, crap, &#$^*# *(#$&*(&$(* (*#&$(* &#*(&$ #( (*#&*( $&(*#, someone find something I can kill ... ... ... ...

OK, now for the details.

The CN node did indeed do it's work properly.
But that still wasn't good enough.

Every single relay shows our block before the f2pool block, even the CN relay.
Every single relay shows our block sent back to us before the f2pool block, even the CN relay.
... the us relays don't show us sending it to the relay coz the solo pool did that faster.

Our time to process the block was 280ms.

I've shortened all the block hashes below to 4 zeros and 4 hex since that's enough to see which is which.

00003e80 is 410418 BTCC in china - all pools worked on this block

*00002b07* is 410419 our block

-00001f67- is 410419 FUPool
00003007 is 410420 FUPool confirming their block

Code:

bjs [2016-05-05 23:35:17.374+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
bjs [2016-05-05 23:38:01.073+00] *00002b07* sent, size 985717 with 37638 bytes on the wire
bjs [2016-05-05 23:38:01.209+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
bjs [2016-05-05 23:38:02.227+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
bjs [2016-05-05 23:44:40.138+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

jpy [2016-05-05 23:35:17.561+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
jpy [2016-05-05 23:38:01.122+00] *00002b07* sent, size 985717 with 37638 bytes on the wire
jpy [2016-05-05 23:38:01.291+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
jpy [2016-05-05 23:38:08.164+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
jpy [2016-05-05 23:44:40.200+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

eu [2016-05-05 23:35:17.641+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
eu [2016-05-05 23:38:01.118+00] *00002b07* sent, size 985717 with 37638 bytes on the wire
eu [2016-05-05 23:38:01.163+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
eu [2016-05-05 23:38:05.960+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
eu [2016-05-05 23:44:40.240+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

us-east [2016-05-05 23:35:17.741+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
us-east [2016-05-05 23:38:01.601+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
us-east [2016-05-05 23:38:08.310+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
us-east [2016-05-05 23:44:40.268+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

us-west [2016-05-05 23:35:17.741+00] 00003e80 recv'd, size 989168 with 6717 bytes on the wire
us-west [2016-05-05 23:38:01.601+00] *00002b07* recv'd, size 985693 with 37546 bytes on the wire
us-west [2016-05-05 23:38:08.310+00] -00001f67- recv'd, size 989649 with 935353 bytes on the wire
us-west [2016-05-05 23:44:40.268+00] 00003007 recv'd, size 755724 with 4191 bytes on the wire

The winner was of course decided by the next block (00003007), but the problem is: why was FUPool not working on our block?

So basically the cause was one or more of the following:
FUPool is REAL slow getting their blocks to the CN relay.
FUPool works on their own blocks after they see other pool blocks if they are found soon after.
FUPool had most of their 410419 block transactions not in the relay so was really slow getting their block into the relay (compression was almost zero as you can see) Edit: but I don't think this is it coz it was prolly the relay did that coz it already had our block using the transactions.

Until you spell our name correctly, you won't be able to understand why you always get orphaned. We haven't have any orphans for 7 weeks, or more than 1400 blocks.

I can smell how racist this thread is: Anything from China is bad. Chinese miners mine at Chinese pools only because they are behind the GFW. Anyone outside of China mining at Chinese pools are evil. Should you reflect on your attitude?

[thedreamer]

I can smell how racist this thread is: Anything from China is bad. Chinese miners mine at Chinese pools only because they are behind the GFW. Anyone outside of China mining at Chinese pools are evil. Should you reflect on your attitude?

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Not much good coming out of china, including Crypo miners/pools/gear.. 

[PassThePopcorn]

I am thinking that this orphan issue is just the tip of the iceberg - beyond this we have our extraordinary bad luck for many days now.

I suspect something has changed and this pool is getting locked out of blocks somehow.  The orphans may/may not be related.

This is exactly what happened at Slush before I moved here.  I'm having a deja vu.

did not want to say this but I did think it.


what is worse is this if this is true it   confirms it:

...


Until you spell our name correctly, you won't be able to understand why you always get orphaned. We haven't have any orphans for 7 weeks, or more than 1400 blocks.

Now take a step back and look at this the leader of the largest pool said this.

  Forget everything about kano.is

 think overall what the claim is :     we can crush you  or orphan you   or waste you   ..


I know of a few ways they can do it.   

so to everyone here that is renting  from NH / WH   consider that

   f2pool can send dead hashers to   WH/NH  with ease   
   f2pool can mine on is own blocks  out of proper order.  they actually did this and caused a fork.
   f2pool  claims they   can always orphan us see above.

If I was able to read the orphaned blocks on blockchain, yeah I know blockchain isn't the best but still...most of the orphan races and wins were either caused or won by F2Pool

[philipma1957]

I can smell how racist this thread is: Anything from China is bad. Chinese miners mine at Chinese pools only because they are behind the GFW. Anyone outside of China mining at Chinese pools are evil. Should you reflect on your attitude?

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Not much good coming out of china, including Crypo miners/pools/gear.. 

Dude that's racist.  And over the top.

 But I can see why you think it.

@ macbook air  your pool is too big   and too much hash is in China.    Not racist just a fact.

It is bad for all crypto coins.     If your government decides to out law or restrict crypto coins  the entire industry will suffer.
Hey all my gear is Chinese other then a few sticks from sidehack. (using bitmain chips) 

 Why is that?  no one sells chips.

Are all chips in China Russia and maybe Israel has some newer chips.

None of them are being sold.   


 Intel and AMD sell cpu chips   in counts of 1 to 1000+

asic builder don't for the most part.   


So people all over the world resent  asic building countries  fact.

I am a white guy.

I resent bitfury --------------(mostly white people) why  they don't sell chips or gear in smaller sales.
I resent Spondoolies---------(mostly white people) why they don't sell chips  or gear in smaller sales
I resent Avalon --------------(mostly Asian I think) why they don't sell chips or gear in smaller sales
I resent bitmaintech---------(mostly Asian I think) why they don't sell chips

But I resent BFL more and they are White americans just like I am why need I say why.

Lastly I resent GAW miners and they are White americans  they are the worst of all as they blueprinted a method of destruction for all coins with their tactics used.



As for pools too much are in China and it simply kills off  diversification of hash.

I feel your pool in particular is using really piss poor tactic that are a variation of GAW/zen mining and they will damage and continue to damage all crypto coins as long as you keep doing them.

[thedreamer]

Dude that's racist.  And over the top.

 But I can see why you think it.

Actually, it's not racist, as I was referring to a country not the asian 'race' as a whole. I love other asian countries and have no problems with those.

I have dealt over the years with Chinese companies and business people as can freely and sternly say what I said before.

If this is a true 'attack' from the biggest Chinese pool to shut up a very effective pool such as KANO.IS is is even worse as they are abusing their power and ruining Bitcoin overall. Even more of a reason to have people stop mining at their low paying junk pool(s). 

[philipma1957]

Dude that's racist.  And over the top.

 But I can see why you think it.

Actually, it's not racist, as I was referring to a country not the asian 'race' as a whole. I love other asian countries and have no problems with those.

I have dealt over the years with Chinese companies and business people as can freely and sternly say what I said before.

If this is a true 'attack' from the biggest Chinese pool to shut up a very effective pool such as KANO.IS is is even worse as they are abusing their power and ruining Bitcoin overall. Even more of a reason to have people stop mining at their low paying junk pool(s). 

 My problem is he said he is really attacking the kano.is pool  not good.

[kano]

...
The winner was of course decided by the next block (00003007), but the problem is: why was FUPool not working on our block?

So basically the cause was one or more of the following:
FUPool is REAL slow getting their blocks to the CN relay.
FUPool works on their own blocks after they see other pool blocks if they are found soon after.
FUPool had most of their 410419 block transactions not in the relay so was really slow getting their block into the relay (compression was almost zero as you can see) Edit: but I don't think this is it coz it was prolly the relay did that coz it already had our block using the transactions.

Until you spell our name correctly, you won't be able to understand why you always get orphaned. We haven't have any orphans for 7 weeks, or more than 1400 blocks.

I can smell how racist this thread is: Anything from China is bad. Chinese miners mine at Chinese pools only because they are behind the GFW. Anyone outside of China mining at Chinese pools are evil. Should you reflect on your attitude?

So firstly this reply is directly to my post.

Where exactly have I said anything at all that's racist?
Point it out to me. Anywhere on the entire forum.

In fact to point out how fucking stupid your comment is, guess what?
Avalon is ... Chinese ...
Yes and I have long known Xiangfu of Canaan-Creative since he first got an Icarus back at the beginning of 2012 and he wrote the first version of the cgminer Icarus driver.

Also ... I've just gone and setup a CN node paying a CN company more than I pay US/EU companies for the same service.
I'm not sure exactly why I'd be paying for and using CN resources if I was racist?

You, however, I'm not sure why you are victimising yourself, maybe you need to see a doctor?
Paranoia can be a tough thing to deal with.

[Sierra8561]

These giant pools giving big miners so much power stands against the fundamentals of bitcoin.

[HerbPean]

you won't be able to understand why you always get orphaned.

Humor me

[kano]

...
The winner was of course decided by the next block (00003007), but the problem is: why was FUPool not working on our block?

So basically the cause was one or more of the following:
FUPool is REAL slow getting their blocks to the CN relay.
FUPool works on their own blocks after they see other pool blocks if they are found soon after.
FUPool had most of their 410419 block transactions not in the relay so was really slow getting their block into the relay (compression was almost zero as you can see) Edit: but I don't think this is it coz it was prolly the relay did that coz it already had our block using the transactions.

Until you spell our name correctly, you won't be able to understand why you always get orphaned. We haven't have any orphans for 7 weeks, or more than 1400 blocks.

Yes we are in a run of low luck, and that is, of course, included in the last 7 weeks of blocks.
The pool luck ~7 weeks, 214 blocks + 4 orphans, is ... 106.4%

So for 7 weeks anyone mining at your pool made less than mining here.
Wow that's gotta suck for anyone who made that mistake.

I'd be wary of letting anyone at your pool know about that fact that they lost out mining at your pool vs mining here for 7 weeks.

[macbook-air]

...
The winner was of course decided by the next block (00003007), but the problem is: why was FUPool not working on our block?

So basically the cause was one or more of the following:
FUPool is REAL slow getting their blocks to the CN relay.
FUPool works on their own blocks after they see other pool blocks if they are found soon after.
FUPool had most of their 410419 block transactions not in the relay so was really slow getting their block into the relay (compression was almost zero as you can see) Edit: but I don't think this is it coz it was prolly the relay did that coz it already had our block using the transactions.

Until you spell our name correctly, you won't be able to understand why you always get orphaned. We haven't have any orphans for 7 weeks, or more than 1400 blocks.

Yes we are in a run of low luck, and that is, of course, included in the last 7 weeks of blocks.
The pool luck ~7 weeks, 214 blocks + 4 orphans, is ... 106.4%

So for 7 weeks anyone mining at your pool made less than mining here.
Wow that's gotta suck for anyone who made that mistake.

I'd be wary of letting anyone at your pool know about that fact that they lost out mining at your pool vs mining here for 7 weeks.

Please stop misleading the miners. Anyone who knows some basic probability and mathematical statistics understands that whatever luck which only represents the past, it cannot predict the future.