Quote from: jedimstr on November 17, 2013, 05:04:09 AM

Quote from: zvs on November 17, 2013, 04:30:10 AM

OK, so I'm guessing people probably use 204.10.105.113:9332/static because of the domain p2pool.org... even though it's horribly set up & has a 2% fee. quite sad really, when one looks at the one month/one year chart. (oh and ofc he never took me up on my offer, no mails from that guy)

now, second question, why do people use elizium.name?... or is it just all local traffic? though I'd be shocked if 95% or more of it wasn't just from random people using a remote p2pool. 400 shares I think is enough to get a trend & 55 orphans is bad. I can see there's 11 outgoing connections, but I guess I'll assume that those are just random outgoing connections? It looks like my node @ 198.12.127.2 used one of its random outgoing connections to hook up w/ it, but not connected to me at the other two places. normally i'd add it to --p2pool-node since it seems to be on a fast enough computer & good connection, but i've just been observing the sub 100% efficiency for the last few days & curiosity killed the cat. Is it all just because of that interface? The most important part is busted (the share explorer).

I also don't understand why so many people use 183.136.216.39:9332/static/graphs.html?Year when it's absolutely horrid. 10 outgoing connections, that are either totally random or not good choices. For location (China), he's not connecting to some critical western US & Russian nodes that he should be on. I *think* it's also on an old version of bitcoind. at least it's at 0% fee

But why would you use that over this: mine.yuyi.tw:9332 a far superior pool in Taiwan with 1/10th the hashrate. This one runs 0% fee too, so that's not it

is there some place i'm missing where these sites are being advertised? reddit? asic hardware manufacturer forums? lol.

some people want to use p2pool for whatever reason, but don't want to spend money on hosting for their own node (I'll assume they live in a crap rural area like myself w/ shit for bandwidth). but why always choose the wrong pools? then you get all the bullshit misinformation about how p2pool pays out less than . yeah, probably cause you were on one of these low efficiency pools or running a local node that was getting 15% orphans and 5% DOA.. though if it weren't for those people, I guess the rest wouldn't be picking up the bonus

but, seriously, who is mining on one of those 3 pools right now and why? is there anyone that reads this thread that does? if not, where are they coming from?

I use Elizium for one of my backup failovers so I can keep on p2pool when my local node is updated and needs to restart. Secondary Backup on BTCGuild. Elizium's current efficiency of 105% isn't bad and they have decent uptime and ping from my location. Of course I only need them for the minute or so when I'm restarting the node after a git pull or the few minutes I need to do a full reboot and system maintenance.

That wouldn't be causing it to get the 4thash then... Grin

Uh, I think all these bizarre miners on my node are just someone loading me up with TCP sockets that never close.

The daily chart at the moment has quite a few:

http://www.nogleg.com:9332/static/graphs.html?Day

This Kyle Rubenok fellow in particular doesn't really seem like a bitcoin miner to me. I've tried to contact a few of those ppl, anyway

Here's an example from dstat:

Code:

------sockets------ --net/eth0- -dsk/total- ---load-avg--- ----interrupts---
tot tcp udp raw frg| recv send| read writ| 1m 5m 15m | 44 54 55
981 940 3 0 0| 108k 603k| 0 0 |0.09 0.21 0.22| 0 0 1403
982 940 3 0 0| 243k 1255k| 0 0 |0.16 0.22 0.23| 0 0 3291
982 940 3 0 0| 79k 622k| 0 24k|0.16 0.22 0.23| 7 0 1092
984 942 3 0 0| 168k 991k| 112k 80k|0.16 0.22 0.23| 18 0 2319
987 945 3 0 0| 289k 911k| 52k 0 |0.16 0.22 0.23| 4 0 1473
987 945 3 0 0| 313k 992k| 0 0 |0.16 0.22 0.23| 0 0 1633
987 945 3 0 0| 284k 881k| 0 0 |0.15 0.22 0.23| 0 0 844
987 945 3 0 0| 181k 1163k| 0 0 |0.27 0.25 0.23| 0 0 2430
987 945 3 0 0| 45k 625k| 0 0 |0.27 0.25 0.23| 0 0 786
989 947 3 0 0| 30k 353k| 0 0 |0.27 0.25 0.23| 0 0 473
992 950 3 0 0| 130k 786k| 0 16k|0.27 0.25 0.23| 4 0 1593
992 950 3 0 0| 56k 418k| 0 0 |0.25 0.24 0.23| 1 0 715
992 950 3 0 0| 190k 1110k| 0 0 |0.25 0.24 0.23| 0 0 2562
992 949 3 0 0| 72k 2964k| 0 0 |0.25 0.24 0.23| 0 0 1437
992 949 3 0 0| 146k 3193k| 0 24k|0.25 0.24 0.23| 6 0 2251
994 951 3 0 0| 94k 3100k|2048k 0 |0.25 0.24 0.23| 5 0 1342
998 955 3 0 0| 73k 3181k| 0 0 |0.23 0.24 0.23| 0 0 1295
998 955 3 0 0| 106k 3168k|2048k 0 |0.23 0.24 0.23| 5 0 1383
998 955 3 0 0| 46k 2527k| 0 0 |0.22 0.24 0.23| 0 0 993
997 954 3 0 0| 122k 1866k| 0 0 |0.22 0.24 0.23| 0 0 1815
997 954 3 0 0| 43k 2023k| 0 0 |0.22 0.24 0.23| 0 0 981
998 955 3 0 0| 48k 2575k| 0 568k|0.22 0.24 0.23| 8 0 1047
998 955 3 0 0| 92k 4088k| 0 0 |0.22 0.24 0.23| 0 0 1328
998 955 3 0 0| 104k 3917k| 0 0 |0.28 0.25 0.23| 0 0 1279
998 955 3 0 0| 96k 4044k| 0 0 |0.28 0.25 0.23| 0 0 1315

the 1st and 2nd numbers being of interest (it was 900 to 1000 in a minute or so)

this also caused a stratum disconnect & some lost shares, though I'm not sure if that's even related to this, since Hetzner itself is getting 600ms ping times and hardcore packetloss as well...

Some ping stats around the same time:

Code:

Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=181ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=183ms TTL=46
Reply from 5.9.24.82: bytes=32 time=182ms TTL=46
Reply from 5.9.24.82: bytes=32 time=181ms TTL=46
Reply from 5.9.24.82: bytes=32 time=181ms TTL=46
Reply from 5.9.24.82: bytes=32 time=179ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=181ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=278ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=278ms TTL=46
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46

Ping statistics for 5.9.24.82:
Packets: Sent = 5596, Received = 5491, Lost = 105 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 179ms, Maximum = 286ms, Average = 186ms

Pinging google.com [74.125.227.238] with 32 bytes of data:
Reply from 74.125.227.238: bytes=32 time=46ms TTL=56
Reply from 74.125.227.238: bytes=32 time=46ms TTL=56

Ping statistics for 74.125.227.238:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 46ms, Average = 46ms

Pinging 5.9.24.81 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 5.9.24.81: bytes=32 time=605ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=604ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=600ms TTL=47
Reply from 5.9.24.81: bytes=32 time=594ms TTL=47
Reply from 5.9.24.81: bytes=32 time=604ms TTL=47
Reply from 5.9.24.81: bytes=32 time=600ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=599ms TTL=47
Reply from 5.9.24.81: bytes=32 time=598ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=603ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=599ms TTL=47
Reply from 5.9.24.81: bytes=32 time=598ms TTL=47
Request timed out.

Ping statistics for 5.9.24.81:
Packets: Sent = 22, Received = 11, Lost = 11 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 594ms, Maximum = 605ms, Average = 600ms

Pinging hetzner.de [213.133.107.227] with 32 bytes of data:
Request timed out.
Reply from 213.133.107.227: bytes=32 time=599ms TTL=47
Request timed out.
Reply from 213.133.107.227: bytes=32 time=599ms TTL=47
Reply from 213.133.107.227: bytes=32 time=598ms TTL=47
Reply from 213.133.107.227: bytes=32 time=598ms TTL=47
Request timed out.
Reply from 213.133.107.227: bytes=32 time=594ms TTL=47
Request timed out.
Reply from 213.133.107.227: bytes=32 time=593ms TTL=47
Reply from 213.133.107.227: bytes=32 time=593ms TTL=47
Request timed out.
Reply from 213.133.107.227: bytes=32 time=589ms TTL=47
Reply from 213.133.107.227: bytes=32 time=594ms TTL=47
Reply from 213.133.107.227: bytes=32 time=589ms TTL=47
Reply from 213.133.107.227: bytes=32 time=574ms TTL=47
Request timed out.
Request timed out.
Reply from 213.133.107.227: bytes=32 time=493ms TTL=47
Reply from 213.133.107.227: bytes=32 time=498ms TTL=47
Reply from 213.133.107.227: bytes=32 time=457ms TTL=47

I don't see why so many people would mine w/ invalid addresses to a p2pool node, honestly. I mean, I've had a big warning written up there for several weeks now.

A couple of the "real" addresses have zero total transactions, but a few are active....

So, are all these locked sockets just being caused by Hetzner's network getting messed up, is there really a dozen or two people not using a valid bitcoin address mining to me over the last week?

Does anyone else get hundreds of dead sockets to 9332?