the bs "Satoshi:0.8.99"

[zvs]

Is there some purpose to these nodes?  They all connect within a few seconds of me restarting bitcoind & appear to do absolutely nothing

Code:

    {
        "addr" : "176.9.144.41:15326",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839970,
        "bytessent" : 155341,
        "bytesrecv" : 1843,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "5.9.245.121:37328",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839969,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "5.9.30.207:37102",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839969,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "5.9.203.20:20099",
        "services" : "00000001",
        "lastsend" : 1382839968,
        "lastrecv" : 1382839968,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "144.76.102.176:22515",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839969,
        "bytessent" : 155341,
        "bytesrecv" : 1843,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "5.9.110.78:60995",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839969,
        "bytessent" : 155341,
        "bytesrecv" : 1843,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "144.76.136.138:40528",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839969,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "144.76.70.73:51414",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839969,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "46.4.64.21:45435",
        "services" : "00000001",
        "lastsend" : 1382839969,
        "lastrecv" : 1382839969,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "88.198.41.74:29099",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839970,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "91.121.58.230:49681",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839969,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },
    {
        "addr" : "199.193.117.231:23601",
        "services" : "00000001",
        "lastsend" : 1382839970,
        "lastrecv" : 1382839970,
        "bytessent" : 1916,
        "bytesrecv" : 1782,
        "conntime" : 1382838949,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.99/",
        "inbound" : true,
        "startingheight" : 1,
        "banscore" : 0
    },

[1713532655]

1713532655

[1713532655]

1713532655

[1713532655]

1713532655

[piotr_n]

Yeah, I've seen them as well.
They do nothing except listening for invs and they never give up - when you disconnect them, they immediately try to reconnect,

The only explanation I have is that they seek to find IP addresses from which new transactions originate.

[Mike Hearn]

Looks like they're mostly hosted at your-server.de

Whoever is doing this, please set your subVer field appropriately. Otherwise it just makes you look like a DoS attacker ....

[piotr_n]

Sorry, mr polite and competent, but I did not catch that point...

How exactly is the guy setting his "subVer field appropriately" going to help anyone with anything here?

And what kid of DoS attacker connects to a node, just to do nothing, except listening for invs?
The node staying idle looks more like it's trying to not DoS attack itself, after being connected to so many peers

[Mike Hearn]

I mean if it's legitimate, setting the subVer to reflect the fact that it's not really a Satoshi 0.8.99 node would be useful for helping people figure out what's connecting to them.

Bitcoin is very easy to DoS today. Each node only accepts (I think?) 120 connections, because each open connection uses some RAM even if it's not doing anything. Thus you can use up all available connection slots by connecting to all the nodes lots of times and it costs you hardly any bandwidth.

[piotr_n]

And I mean that these nodes seem to be there to not do any DoS attacks, but rather to collect information, so changing the subVer won't change a bit in the matter.

And BTW these spying nodes have been there for at least a month and I even have this issue addressed deep on my todo list.

[gmaxwell]

FWIW, these are also the same nodes which have been triggering the incorrect time warnings.

[btceic]

And I mean that these nodes seem to be there to not do any DoS attacks, but rather to collect information, so changing the subVer won't change a bit in the matter.

And BTW these spying nodes have been there for at least a month and I even have this issue addressed deep on my todo list.

Whats a spying node?

Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?

[gmaxwell]

Whats a spying node?
Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?

They may, BC.i runs nodes that do this. I've seen other aggressive connectors in the past, and surveillance is one of the possible explanations for them but for most of them it's impossible to know for sure.

There are more benign explanations though. For example, some people erroneously believe that connecting to large numbers of nodes is in their interest— e.g. they're miners and they think it will improve their block propagation, in fact because the relaying is sequential it generally tends to hurt your block propagation to do this... and they go around addnode=ing hundreds of nodes.

I've spent a fair amount of time trying to figure out how the network can discourage this kind of behavior and don't have any great general solutions.  So far the best I can do is prevent mass-connectors from DOSing the whole network. For anti-spying the best I can suggest right now is moving your nodes behind tor.

[piotr_n]

Whats a spying node?

Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?

Yes.

What can be an other reason for a node that keeps connecting to you and after connected is only listening for invs, though never asking for any data?
The only reason that comes to my mind is that it tries to collect IP addresses where new invs originate from. Might also be for new blocks - not necessarily only for transactions.

And that I call a spying node, though you can call it whatever you like. A curious node, for instance

[disclosure]

It looks like an attempt to connect to all nodes in the network at once. Perhaps for realtime stats of the network?

[behindtext]

Whats a spying node?

Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?

i haven't spent any time profiling the traffic myself, but i imagine that if you know or have some good guesses as to which bitcoind instances correspond to particular people or organizations and make a point to connect to many servers, you could use the info to infer the author of each tx.

without digging in, it's hard to tell who would be mining such information from the network. i would expect it to be one or more of the following groups to be doing this:

* black hatters looking for targets to hack that may have coins
* intelligence and law enforcement organizations trying to de-anonymize users
* banks determining which jurisdictions to be most worried about with adoption and usage

[Mike Hearn]

The other thing we could do is start to politely disconnect nodes that appear to be forging their subVer field. Unfortunately the lack of any kind of error message in the protocol means there's no way to send a message to the node before it's disconnected ....

[runeks]

It looks like an attempt to connect to all nodes in the network at once. Perhaps for realtime stats of the network?

Or perhaps they just want to see where each transaction originates from, so they can map IP addresses to nodes? If a single node is connected to every node in the network, then - provided that a node will publish a transaction to all the nodes it is connected to - it will know that the transactions it receives originates from the node it gets it from.

[zvs]

Whats a spying node?
Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?

They may, BC.i runs nodes that do this. I've seen other aggressive connectors in the past, and surveillance is one of the possible explanations for them but for most of them it's impossible to know for sure.

There are more benign explanations though. For example, some people erroneously believe that connecting to large numbers of nodes is in their interest— e.g. they're miners and they think it will improve their block propagation, in fact because the relaying is sequential it generally tends to hurt your block propagation to do this... and they go around addnode=ing hundreds of nodes.

I've spent a fair amount of time trying to figure out how the network can discourage this kind of behavior and don't have any great general solutions.  So far the best I can do is prevent mass-connectors from DOSing the whole network. For anti-spying the best I can suggest right now is moving your nodes behind tor.

Well, this leads to something interesting, I guess.

I usually run with ~500 peers connected & I noticed all those eth zurich nodes, so I did a bitcoind addnode on all 31 of them.  After that, I noticed I started getting quite a few block orphans....  re:  I'd never receive block 1.. I'd end up getting block 2 and block 3, before finally getting sent block 1.

This hasn't been a problem since I firewalled 129.132.0.0.  If you look at blockchain.info, you'll notice that on a lot of these blocks "discovered" by 129.132.x.x, they'll propagate quite slowly.

I put one example here:



block 266494, zero transactions, 2.6kb is size...  this is 2m after block was first seen.  

I've never spent much time looking at the code, but my guess is that nodes request the block from them & they answer this request but never send the block?

I guess I could *also* note that when I had all 31 as peers, I never received a block from any of them.

(ed: not a huge impact on the major pools, since they're all pretty much linked, but I guess a solo miner might get dinged)

[Peter Todd]

The other thing we could do is start to politely disconnect nodes that appear to be forging their subVer field. Unfortunately the lack of any kind of error message in the protocol means there's no way to send a message to the node before it's disconnected ....

Suggestions on how to do this that won't turn into a game of whack-a-mole?

[Mike Hearn]

If they're determined to forge a fake subVer then it won't help much. If they're doing that because they're lazy or because they just modified a regular Satoshi codebase and forgot, then it might give them the incentive they need to announce themselves in a useful manner.

[Peter Todd]

If they're determined to forge a fake subVer then it won't help much. If they're doing that because they're lazy or because they just modified a regular Satoshi codebase and forgot, then it might give them the incentive they need to announce themselves in a useful manner.

Right, so whack-a-mole, even in the best case.

We're better off figuring out better ways of detecting useless peers and dropping them than wasting time coming up with case-specific fixes.

[Mike Hearn]

It's the same thing. A real bitcoind node isn't useless, so if a useless node claims to be a Satoshi node, we know it's not.

[kjj]

FWIW, these are also the same nodes which have been triggering the incorrect time warnings.

We should have fixed the time nonsense in bitcoin long ago.

Despite the imperfections of NTP, there is no excuse for a p2p network (which runs on the same internet as NTP) to fudge the clock.  If I have a good NTP lock, and I connect to a node with a different time, that node is wrong and should be kicked immediately.  If I don't have a good NTP lock and I connect to a node which does, that node should kick me.

I don't know that making whatever this is fix their clocks will cure anything, but it can't hurt, and we should have done it long ago.