Agreed. The restriction should be effective on inbound and outbound connections alike. And that is a fairly easy patch to write.
Topic: the bs "Satoshi:0.8.99" (Read 6390 times)
If you are running a bitcoin listening node on Linux, this example iptables rule would help to limit the number of incoming connections coming from the same IPv4 subnet.
So the bitcoind built-in /16 restriction (https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1331) is not working?
That is outbound, there is no limit for inbound. One IP address could theoretically fill all incoming listening slots of the entire world. That is unless they used something like my iptables rule above. Some of the devs indicated that they would welcome an option for this kind of behavior in bitcoind itself.
I would think being listed in the peer list (getpeerinfo) means the bitcoind has successfully exchanged packets/handshaked with its peers. Even if the restriction is outbound (outgoing packets), it still does not make sense for the multiple nodes from the same /16 to be able to establish connection with my bitcoind.
They don't act like the spying nodes from the OP, though - they do send invs, sometimes even very fresh ones.
source: https://blockchain.info/pools
It might be a miner's solution to speed up a propagation time of the blocks it mines.
source: https://blockchain.info/pools
It might be a miner's solution to speed up a propagation time of the blocks it mines.
If you are running a bitcoin listening node on Linux, this example iptables rule would help to limit the number of incoming connections coming from the same IPv4 subnet.
So the bitcoind built-in /16 restriction (https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1331) is not working?
That is outbound, there is no limit for inbound. One IP address could theoretically fill all incoming listening slots of the entire world. That is unless they used something like my iptables rule above. Some of the devs indicated that they would welcome an option for this kind of behavior in bitcoind itself.
If you are running a bitcoin listening node on Linux, this example iptables rule would help to limit the number of incoming connections coming from the same IPv4 subnet.
So the bitcoind built-in /16 restriction (https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1331) is not working?
This subnet is owned by a Swiss academic institution:
http://whois.domaintools.com/129.132.230.0
If anyone knows who this group is, can they please make them aware of the difficulties they are causing?
http://whois.domaintools.com/129.132.230.0
If anyone knows who this group is, can they please make them aware of the difficulties they are causing?
If you are running a bitcoin listening node on Linux, this example iptables rule would help to limit the number of incoming connections coming from the same IPv4 subnet.
Code:
# Reject TCP connection if quantity of connections per class C network is exceeded.
# "--connlimit-above 2" is default in this example. The limit can be increased if
# your server has sufficient RAM to handle an increased bitcoin.conf maxconnections=
# parameter much higher than the default 150 simultaneous connections.
-A INPUT -p tcp --syn --dport 8333 -m connlimit --connlimit-above 2 --connlimit-mask 24 -j REJECT --reject-with tcp-reset
# Allow TCP connection if not rejected by the previous limit
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8333 -j ACCEPT
# This TCP connection limit per source class C subnet is similar to a Slowloris
# HTTP DoS mitigation measure, except it is safe to have a very small limit.
# It is non-fatal for legitimate clients to fail to connect because there exist
# plenty of other legitimate nodes to choose from that offer the same service.
# It is more important to allow random, distributed clients to connect with a 90%
# success rate than it is to that ensure 100% of clients are able to connect.
My bitcoind is configured to accept max. 32 connections, i.e. maxconnections=32 in bitcoin.conf. Now I am seeing this:
They took 70% of my connections. All from the same network with IP address 129.132.230.*. I thought bitcoind is hardcoded to accept only 1 peer per /16 network??
Code:
$ ./bitcoind getpeerinfo | grep BTC-ETHZ | wc -l
23
$ ./bitcoind getpeerinfo | grep 129.132.230 | wc -l
23
$ ./bitcoind getpeerinfo | grep 0.8.99 | wc -l
23
They took 70% of my connections. All from the same network with IP address 129.132.230.*. I thought bitcoind is hardcoded to accept only 1 peer per /16 network??
Jut curious but does bitcoind support IP blacklisting. Yeah it probably can (and would be better done) at the firewall level but this topic just made me wonder if there is any config option in bitcoind.
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 ....
The same hosting IP space of bitcoincharts/bitcoinwatch... Whoever is doing this, please set your subVer field appropriately. Otherwise it just makes you look like a DoS attacker ....
Did you guys also notice that there is an entire subnet 129.132.230.0/24 doing quite a similar stuff...?
By the way, they are considered "hub nodes" by blockchain.info https://blockchain.info/hub-nodes
Their subver is somewhat different
Code:
{
"addr" : "129.132.230.69:41037",
"services" : "00000001",
"lastsend" : 1383962848,
"lastrecv" : 1383962839,
"bytessent" : 110486,
"bytesrecv" : 74817,
"conntime" : 1383962013,
"version" : 70001,
"subver" : "/BTC-ETHZ:0.8.99/",
"inbound" : true,
"startingheight" : 268607,
"banscore" : 0,
"syncnode" : true
},What does it have to do with ETH Zurich?
It's interesting because ETHZ had quite a few publications about bitcoin.
Did you guys also notice that there is an entire subnet 129.132.230.0/24 doing quite a similar stuff...?
You're right @Cryddit - it's a good solution to broadcast your own txs slowly, like each new second you send it to another peer... there is no rush with it anyway.
But I think they might also be spying for mining nodes - and a mining node wants to propagate new blocks as quickly as possible.
So that's a tough problem to solve.
What I do in my client now, I never broadcast locally created txs to nodes that have not sent me any inv.
But when they find out what I do, its easy to circumvent - all they need to do is send me an inv once for awhile.
But I think they might also be spying for mining nodes - and a mining node wants to propagate new blocks as quickly as possible.
So that's a tough problem to solve.
What I do in my client now, I never broadcast locally created txs to nodes that have not sent me any inv.
But when they find out what I do, its easy to circumvent - all they need to do is send me an inv once for awhile.
Suggestions on how to do this that won't turn into a game of whack-a-mole?
I think that these nodes are listening to see where transactions originate. As long as, by listening, they can see where transactions originate, they will continue to listen. The only way to get rid of them is to deprive them of the ability to obtain the information they seek. They are worth getting rid of because they fail to follow protocol in propagation of tx and block information. If this defection from protocol becomes widespread it constitutes a DoS attack, wherein nodes are cut off from the network by having their connections clogged with these useless fake clients.
Obtaining the information they seek relies on the fact that the current client propagates transactions to all connected nodes, including them.
The only way to get rid of them, therefore, is to quit doing that. Instead, propagate a new transaction to one, two, or three nodes, regardless of how many are connected. Propagate a received transaction to nine or ten nodes, regardless of how many are connected.
That will make it very difficult for these eavesdroppers to tell where new transactions originate. And hopefully it will deprive their owners of the motivation to continue to keep up this attack.
oh, re: the stuff I said earlier
another nice example, when one checks block 266619
normally you'd just get some getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 in there, not all the requests for block 266619 and 266620 (and in some cases 266618, 266619, and 266620)
needs changing on handling of block requests i would think
Code:
2013-10-28 23:47:36 received block 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa
2013-10-28 23:47:36 Committing 6844 changed transactions to coin database...
2013-10-28 23:47:36 SetBestChain: new best=000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa height=266620 log2_work=73.28903 tx=26163172 date=2013-10-28 23:47:57 progress=1.000002
2013-10-28 23:47:36 ProcessBlock: ACCEPTED
2013-10-28 23:47:36 getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
2013-10-28 23:47:36 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:36 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266618 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266618 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266618 to 00000000000000095f2b79ac211d800ca268f58d2429b049d2fd64e68ba8db3c limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:38 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:38 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:38 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:39 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
another nice example, when one checks block 266619
normally you'd just get some getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 in there, not all the requests for block 266619 and 266620 (and in some cases 266618, 266619, and 266620)
needs changing on handling of block requests i would think
Uh. NTP is pretty much completely insecure in practice. And if you have free control of time you can inflate bitcoin randomly. At the same time, nodes don't really need precise time.
There is insecure, and then there is insecure. Are there any real world attacks that don't require the attacker to be in a position where they could do much worse?
Also, note that the time data used by the bitcoin network is also totally unauthenticated and insecure. Our pseudoclock is adjusted based on the version message timestamp, which is trivial to modify. We even potentially reject blocks (which contain a somewhat secure timestamp) based partially on data collected from the totally insecure timestamps reported in the unauthenticated version messages.
Hell, for all we know, the bogus timestamps from these nodes are a real world attack test.
I know that bitcoin doesn't need an accurate clock, but every node on the network has an accurate clock available anyway.
No one should be doing serious work on the internet without a solid clock, and money is about as serious as serious gets.
Bitcoin can handle a clock that's off by roughly an hour off just fine. Clock accuracy just isn't a big deal.
We were smart enough to avoid creating our own PKI in favor of the existing system that is good enough. Why aren't we smart enough to avoid creating our own clock synchronization system?
We didn't create a clock synchronization system, we created a peer averaging system. Think correctness vs. consensus.
Also, if the PKI in the payment protocol is attacked, all that happens is some users lose their money. If there is a wide-spread NTP attack, especially affecting miners, the whole system can collapse.
Uh. NTP is pretty much completely insecure in practice. And if you have free control of time you can inflate bitcoin randomly. At the same time, nodes don't really need precise time.
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.
Emphasis on if
Unfortunately we can't just ship bitcoind out of the box with NTP support, because then whatever NTP servers we use - even if we use a whole bunch - suddenly become a central point of control of the whole Bitcoin network. This is made even worse by how NTP isn't authenticated.
Maybe we could get away with abusing https and timestamping servers based on the logic they won't want to be proven to be lying, especially the latter, but ultimately we really just want users to set their damn clocks right.
It's ugly and there's no good solution to the problem unfortunately. Satoshi should have picked something more like a six or twelve hour window, rather than two, but widening that window now is a hard-fork even to SPV clients.
Why would we need to include NTP? Is there some OS out there with network support that can run a bitcoin node, but not NTP?
No one should be doing serious work on the internet without a solid clock, and money is about as serious as serious gets.
After a while, this really degenerates into the SSL debate. SSL sucks. Why does everyone use it? Because everything else is worse. NTP sucks. Why does everyone use it? Because everything else (including bitcoind's crappy pseudo-NTP) is worse.
We were smart enough to avoid creating our own PKI in favor of the existing system that is good enough. Why aren't we smart enough to avoid creating our own clock synchronization system?
P.S. pool.ntp.org. The Air Force could probably mess with it if they were willing to crash some planes, but I doubt that anyone else could do much damage. I know we have some timekeeping enthusiasts around. Is the NTP pool more vulnerable than I'm aware of?
Edit 2013-10-28 19:32: removed an extra "a"
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.
Emphasis on if
Unfortunately we can't just ship bitcoind out of the box with NTP support, because then whatever NTP servers we use - even if we use a whole bunch - suddenly become a central point of control of the whole Bitcoin network. This is made even worse by how NTP isn't authenticated.
Maybe we could get away with abusing https and timestamping servers based on the logic they won't want to be proven to be lying, especially the latter, but ultimately we really just want users to set their damn clocks right.
It's ugly and there's no good solution to the problem unfortunately. Satoshi should have picked something more like a six or twelve hour window, rather than two, but widening that window now is a hard-fork even to SPV clients.
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.
Right, but if we know it's useless, who cares what subver it claims?
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.
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.
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.
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.
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?
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.Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?
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)
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.
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 ....
Whats a spying node?
Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?
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
It looks like an attempt to connect to all nodes in the network at once. Perhaps for realtime stats of the network?
Whats a spying node?
Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?
Yes.Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?
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
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.Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?
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.
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.
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?
FWIW, these are also the same nodes which have been triggering the incorrect time warnings.
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.
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.
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.
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.
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
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
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 ....
Whoever is doing this, please set your subVer field appropriately. Otherwise it just makes you look like a DoS attacker ....
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.
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.
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
},
"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
},
Jump to: