Peer 82.130.xx.xx connected to me 3 times, sending constant pings?

[zvs]

09/18/12 12:41:03 accepted connection 82.130.xx.xx:51434
09/18/12 12:41:03 send version message: version 60002, blocks=199384, us=5.9.xx.xx:8333, them=82.130.xx.xx:51434, peer=82.130.xx.xx:51434
09/18/12 12:41:03 receive version message: version 60001, blocks=0, us=5.9.xx.xx:8333, them=82.130.xx.xx:51196, peer=82.130.xx.xx:51434
09/18/12 12:54:45 accepted connection 82.130.xx.xx:57620
09/18/12 12:54:45 send version message: version 60002, blocks=199384, us=5.9.xx.xx:8333, them=82.130.xx.xx:57620, peer=82.130.xx.xx:57620
09/18/12 12:54:45 receive version message: version 60001, blocks=0, us=5.9.xx.xx:8333, them=82.130.xx.xx:39389, peer=82.130.xx.xx:57620
09/18/12 12:58:35 accepted connection 82.130.xx.xx:59080
09/18/12 12:58:35 send version message: version 60002, blocks=199385, us=5.9.xx.xx:8333, them=82.130.xx.xx:59080, peer=82.130.xx.xx:59080
09/18/12 12:58:35 receive version message: version 60001, blocks=0, us=5.9.xx.xx:8333, them=82.130.xx.xx:58187, peer=82.130.xx.xx:59080
09/18/12 16:29:38 disconnecting node 82.130.xx.xx:51434
09/18/12 16:29:38 disconnecting node 82.130.xx.xx:57620
09/18/12 16:29:38 disconnecting node 82.130.xx.xx:59080

I used tcpkill to drop the connections.

The log:


09/18/12 12:41:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:41:03 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:46:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:46:03 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:51:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:51:03 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:54:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:54:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:56:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:56:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:58:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:58:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:59:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:59:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:01:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:01:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:03:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:03:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:04:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:04:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:06:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:06:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:08:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:08:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:09:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:09:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:11:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:11:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:13:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:13:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:14:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:14:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:16:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:16:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:18:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:18:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:19:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:19:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:21:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:21:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:23:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:23:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:24:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:24:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:26:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:26:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:28:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:28:35 ProcessMessage(ping, 0 bytes) FAILED

<snip>

09/18/12 16:16:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:16:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:18:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:18:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:19:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:19:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:21:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:21:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:23:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:23:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:24:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:24:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:26:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:26:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:28:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:28:35 ProcessMessage(ping, 0 bytes) FAILED

(they have stopped since the tcpkill)

Any particular reason for something like that?

[zvs]

actually, this is really annoying now, since there are 9 of them

206.12.16.155
129.74.74.20
128.6.192.156
129.130.252.140
82.130.102.160 (on about 30 or 40 different ports)
137.99.11.86
130.253.21.123
147.102.3.117
129.130.252.141

whenever one connects, i get flooded with the ping fail

[zvs]

http://blockchain.info/block-index/309780/00000000000005d0f255281c808ee141c282fa1d2918facaa489be13ce27b48d
http://blockchain.info/block-index/309781/00000000000001a7888ef6bfe3e726c2bc7a28e7cbf4549b6d7c3b9711ce194c

removing all the block checks helps, too

[nomnomnom]

This is interesting,

if i put connect=82.130.102.160 in my bitcoin.conf, connection immediately fails
with an error. These node(s) seem to be broken somehow, what could cause this?

Code:

Bitcoin version v0.7.0.3-g0a4e67a-beta ()
[...]
Done loading
send version message: version 60002, blocks=199752, us=0.0.0.0:0, them=0.0.0.0:0, peer=127.0.0.1:0
ThreadRPCServer started
DNS seeding disabled
ThreadIRCSeed exited
ThreadSocketHandler started
ThreadOpenAddedConnections started
ThreadOpenAddedConnections exited
ThreadOpenConnections started
trying connection 82.130.102.160 lastseen=0.0hrs
ThreadMessageHandler started
Flushed 13190 addresses to peers.dat  24ms
connected 82.130.102.160
send version message: version 60002, blocks=199752, us=0.0.0.0:0, them=82.130.102.160:8333, peer=82.130.102.160:8333
Added time data, samples 2, offset +4 (+0 minutes)
receive version message: version 60001, blocks=0, us=88.76.62.34:59196, them=82.130.102.160:8333, 
peer=82.130.102.160:8333
ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message 
being shorter than its stated length
ProcessMessage(ping, 0 bytes) FAILED

[zvs]

This is interesting,

if i put connect=82.130.102.160 in my bitcoin.conf, connection immediately fails
with an error. These node(s) seem to be broken somehow, what could cause this?

Code:

Bitcoin version v0.7.0.3-g0a4e67a-beta ()
[...]
Done loading
send version message: version 60002, blocks=199752, us=0.0.0.0:0, them=0.0.0.0:0, peer=127.0.0.1:0
ThreadRPCServer started
DNS seeding disabled
ThreadIRCSeed exited
ThreadSocketHandler started
ThreadOpenAddedConnections started
ThreadOpenAddedConnections exited
ThreadOpenConnections started
trying connection 82.130.102.160 lastseen=0.0hrs
ThreadMessageHandler started
Flushed 13190 addresses to peers.dat  24ms
connected 82.130.102.160
send version message: version 60002, blocks=199752, us=0.0.0.0:0, them=82.130.102.160:8333, peer=82.130.102.160:8333
Added time data, samples 2, offset +4 (+0 minutes)
receive version message: version 60001, blocks=0, us=88.76.62.34:59196, them=82.130.102.160:8333, 
peer=82.130.102.160:8333
ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message 
being shorter than its stated length
ProcessMessage(ping, 0 bytes) FAILED

Not sure, that's what I was curious about in the original post.  The more of them that connect to you, the more of those messages you'll get.  I checked my log and noticed those appearing again and tracked it down to a new node @ 192.12.33.100.   82.130.102.160 also has at least a few ports open, can see @ http://luke.dashjr.org/programs/bitcoin/files/charts/seeds.txt ... search for Snoopy..   not all of 'em are running, but when I tcpkilled it there were 3 diff processes all from that same IP. 

I thought it might be some nifty feature/optimization of their software that was relaying the blocks so fast, but I guess a lot of it is probably the removal of some (or all) of the block checks, seeing as how they relayed both of those blocks (same height, the orphan about 2-3 minutes late)

[nomnomnom]

Ah ok, Snoopy:0.1

this really seems to be something custom, also note that most of them (the Snoopy:0.1) have 0 blocks.

[zvs]

there is a 129.74.74.19 now, as well.   probably will just start firewalling subnets

besides the snoopy thing, you can just look at who relayed both of height 200625 blocks

http://blockchain.info/block-index/309829/00000000000002f088d717b7dd96d0dfc6adfbc8ad33776080961a85b66f7470
http://blockchain.info/block-index/309830/00000000000004ec4d02d7df12fec552ced6d7b1f1e2e7ea4b11ce3227921860

 it's pretty fast verifying blocks when you turn off  the checks ,  i guess.  esp the transactions

[zvs]

haha, reorganize my ass,   think the source code needs some modification

wtf is btcguild doing with a block that is 2m late?    also running some shit that doesnt proof check blocks?

09/26/12 23:08:57 received block 000000000000037261e3 from
09/26/12 23:08:57 SetBestChain: new best=000000000000037261e3  height=200660  work=501601906478243162700  date=09/26/12 23:08:48
09/26/12 23:08:57 ProcessBlock: ACCEPTED
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:57 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:58 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:59 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:08:59 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:00 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:00 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:00 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:00 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:00 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:00 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:00 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:01 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:02 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:03 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:05 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:05 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:05 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:05 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:05 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:05 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:06 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:06 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:08 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:08 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:09 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:09 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:10 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:11 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:11 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:11 getblocks -1 to 00000000000000000000 limit 500 from
09/26/12 23:09:13 getblocks -1 to 00000000000000000000 limit 500 from

.........................

09/26/12 23:10:50 received block 000000000000058a8c6c from
09/26/12 23:10:50 ProcessBlock: ACCEPTED orphan 000000000000058a8c6c

........................

09/26/12 23:17:18 received block 00000000000004a18738 from
09/26/12 23:17:18 REORGANIZE
09/26/12 23:17:18 REORGANIZE: Disconnect 1 blocks; 00000000000000d0898b..000000000000037261e3
09/26/12 23:17:18 REORGANIZE: Connect 2 blocks; 00000000000000d0898b..00000000000004a18738






btcguild ====== 50btc?

[Kaliecious]

https://bitcointalk.org/index.php?topic=113654.0

This might help

[elux]

http://bgp.he.net/ip/82.130.102.160

ETH Zürich have been experimenting with fast double spend attacks, and is currently (as of today) bringing massive mining power to bear on the main network.

Their public http server has a file named BitThief.exe on it, and they're spamming ping messages. (Denial of Service?) Did i miss anything?

[BC12345]

actually, this is really annoying now, since there are 9 of them

206.12.16.155
129.74.74.20
128.6.192.156
129.130.252.140
82.130.102.160 (on about 30 or 40 different ports)
137.99.11.86
130.253.21.123
147.102.3.117
129.130.252.141

whenever one connects, i get flooded with the ping fail

http://bgp.he.net/ip/206.12.16.155     -->BCnet
http://bgp.he.net/ip/129.74.74.20       -->University of Notre Dame
http://bgp.he.net/ip/128.6.192.156     -->Rutgers University
http://bgp.he.net/ip/129.130.252.140 -->Kansas State University
http://bgp.he.net/ip/82.130.102.160   -->Swiss Federal Institute of Technology Zurich
http://bgp.he.net/ip/137.99.11.86       -->University of Connecticut
http://bgp.he.net/ip/130.253.21.123   -->University of Denver
http://bgp.he.net/ip/147.102.3.117     -->National Technical University of Athens
http://bgp.he.net/ip/129.130.252.141 -->Kansas State University

[gmaxwell]

http://bgp.he.net/ip/82.130.102.160
ETH Zürich have been experimenting with fast double spend attacks, and is currently (as of today) bringing massive mining power to bear on the main network.
Their public http server has a file named BitThief.exe on it, and they're spamming ping messages. (Denial of Service?) Did i miss anything?

Blockchain.info's block source identification is frequently wrong. Try not to panic over it.

[finkleshnorts]

actually, this is really annoying now, since there are 9 of them

206.12.16.155
129.74.74.20
128.6.192.156
129.130.252.140
82.130.102.160 (on about 30 or 40 different ports)
137.99.11.86
130.253.21.123
147.102.3.117
129.130.252.141

whenever one connects, i get flooded with the ping fail

http://bgp.he.net/ip/206.12.16.155     -->BCnet
http://bgp.he.net/ip/129.74.74.20       -->University of Notre Dame
http://bgp.he.net/ip/128.6.192.156     -->Rutgers University
http://bgp.he.net/ip/129.130.252.140 -->Kansas State University
http://bgp.he.net/ip/82.130.102.160   -->Swiss Federal Institute of Technology Zurich
http://bgp.he.net/ip/137.99.11.86       -->University of Connecticut
http://bgp.he.net/ip/130.253.21.123   -->University of Denver
http://bgp.he.net/ip/147.102.3.117     -->National Technical University of Athens
http://bgp.he.net/ip/129.130.252.141 -->Kansas State University

Is this a coordinated effort, since they are all doing the same thing?

[Remember remember the 5th of November]

Their public http server has a file named BitThief.exe

Wallet stealer?

[makomk]

Ah ok, Snoopy:0.1

this really seems to be something custom, also note that most of them (the Snoopy:0.1) have 0 blocks.

There's a download on http://82.130.102.160/ called snoopy.tar.bz2. Appears to be a Python program bundled into a binary. Hmmmm.

[elux]

Their public http server has a file named BitThief.exe

Wallet stealer?

I believe BitThief was shown to be non-bitcoin related.

It seems like Bitthief is not related to Bitcoins:

http://bitthief.ethz.ch/

[zvs]

they aren't mining blocks, they just weren't verifying any of the blocks that they were relaying, hence blockchain.info reporting them relaying the block first

all those ^^ IPs I listed, I had their entire subnets banned on my 5.9.24.81 node

nobody else seemed to tho ,