Topic: This message was too old and has been purged - page 5. (Read 37905 times)

Making this the default behavior would help both Bitcoin and Tor.
It seems that many synergies could be established between the two projects, since both are disruptive enough to attract the attention of big bad actors.

Surely what they are saying they are doing is not really possible.  They cannot with certainty verify who is paying who.  They might be able to make probabilistic statements, but not certainty in all cases. 

nice find!

https://chainalysis.com/

"Chainalysis offers a service that provides financial institutions with the means to obtain regulatory compliance through real-time analysis of the blockchain. Chainalysis customers get access to an API that allows them to determine which entity a transaction originates from, and whether the flow of funds originate from someone they would want to do business with. In other words, it automates the travel rule.
Chainalysis achieves this by doing sophisticated in-depth real-time transaction analysis to determine unique entities within the blockchain.
Besides for API access, customers are provided with a web interface enabling them with easy transaction route investigation, private annotation of entities and transactions and automated report generation."

seems to be them....

I noticed that one of those nodes were connected to my own node, then I scanned it:

Starting Nmap 6.00 ( http://nmap.org ) at 2015-03-13 01:48 CET
Nmap scan report for 46.105.210.179
Host is up (0.065s latency).
Not shown: 996 closed ports
PORT     STATE    SERVICE
22/tcp   open     ssh
445/tcp  filtered microsoft-ds
8080/tcp open     http-proxy
8333/tcp open     unknown

Seeing it had a http-proxy, I connected to it with a browser and got this message, in a typical login box you get with .htaccess restrictions:

A username and password are being requested by http://46.105.210.179:8080. The site says:

 "Please authenticate using your Chainalysis API-ID and API-Key". [sic]

I tried another IP, same result. These are the offending IP's that has connected to my node:

46.105.210.194, 46.105.210.11, 46.105.210.255, 46.105.210.138, 46.105.210.196, 46.105.210.246, 46.105.210.220, 46.105.210.204, 46.105.210.179, 46.105.210.189, 46.105.210.10, 46.105.210.42


And then a google search which gave me:

https://chainalysis.com/

"Providing technical solutions to automate crypto currency compliance"

"
Company

Chainalysis offers a service that provides financial institutions with the means to obtain regulatory compliance through real-time analysis of the blockchain. Chainalysis customers get access to an API that allows them to determine which entity a transaction originates from, and whether the flow of funds originate from someone they would want to do business with. In other words, it automates the travel rule.

Chainalysis achieves this by doing sophisticated in-depth real-time transaction analysis to determine unique entities within the blockchain.

Besides for API access, customers are provided with a web interface enabling them with easy transaction route investigation, private annotation of entities and transactions and automated report generation."


Michael Grønager
Chief Executive Officer

Jan Møller
Chief Technology Officer

Jens Hilligsøe
DevOps Engineer

Kresten Krab Throup
Consulting Architect

Jørn Larsen
Business Advisor


Personally I've perma-blocked these guys now. I should make the iptables rules persistent on my node. Also, is there a blacklist where bad actors are listed with a reason, so a node operator could chose to block such entities? Personally I don't like blacklists much, perhaps whitelists are better, but it's impossible to keep track of every time someone posts about bad nodes.

I understand the need for such a solution as chainalysis from a regulatory and business perspective, however I'm don't think this is in the true spirit of bitcoin, but I guess someone would've provided this kind of service no matter what. But this is akin to spying to be honest. And it is exactly that we're wanting to get away from with all the monitoring that goes on in the traditional financial system. If Joe pays Alice 10 bucks, it's noone's damn business how, where and what relates to that payment.

Ah, so there is a NAT device involved here. This basically invalidates all your previous observations, as they can be explained easily as the errors in the NAT implementation. Especially if somebody advertises "full cone NAT" (only relevant to UDP) when interfacing TCP application.

Please do us all a favor and tell us the manufacturer/model/version information for your NAT box. Everyone could then just add it to they "do not use/buy" list.

Select has a maximum of FD_SETSIZE (1024) FDs in use, and you will end up totally screwed up if you are beyond that. It doesn't matter what you've set your ulimit to.

When you run hacked up versions that which changes that you do not understand you waste everyone's time (including yours), and you provide bad service to other nodes. I shouldn't have to read between the lines to troubleshoot your private code based on the subtle implications of your offhand comments.

This would be pointless. If you are both hosts A and B, why bother having B pretend to be host A?   Also if you were having B pretend to be A your host would still think it was connected to A even if it were now B talking.  I'm doubtful any retail hosting provider of any scale is failing to run URPF these days in any case, since they'd constantly be a source of DOS attacks.


All that aside-- even ignoring what looks like some broken behavior in your node, this is moderately concerning.  What it looks like to me is a rather ham-fisted sybil attack trying to trick nodes into leaking private data to them, the nodes seem to fail to relay transactions too which hurts performance some-- it may even completely disrupt some less sophisticated wallets that don't have any protection against multiple output connections to the same /16. The Bitcoin protocol, when implemented correctly, has a degree of sybil resistance when it comes to partitioning and double-spend risk as an attacker must get _all_ your connections for those attacks, but this kind of activity can really violate user privacy since privacy attacks don't need to get all your connections; especially for SPV nodes which liberally broadcast their wallet addresses to nodes that they're using as servers.

We've been working slowly on some improvements in this space in Bitcoin Core but Bitcoin community (outside of core devs) interest level is pretty low, and due to not being SPV Core already has much better privacy. (In general I've be disappointed by how few people realize how important privacy and fungibility is for Bitcoin's viability as a currency).  It's not as simple as just blocking them (though you're free to do that yourself), as blocking on a global basis (instead of each user deciding for themselves) has significant collateral risk and would be easily evaded by anyone who thought it was okay to breach normal network behavior to violate user privacy in the first place; and then you have even less information about the attack.  Making it so the attack is harder to see doesn't make it go away.

This is also a reminder to always use tor with Bitcoin 100% of the time (and to use a full node if you can), as that reduces the incentives to pull this kind of stunt.

This message was too old and has been purged

Considering that OVH provides 256 IP for free with each dedicated server, I bet 10 satoshis that we have a single monitoring node behind all these IPs.

2000 connections is not possible, you'll run out of file descriptors. If you edit the code remove the limits you'll end up with arbitrary memory corruption.

The code that limits outbound counts to one host per /16 is trivial, it's in net.cpp:1207.   Can you please get a getpeerinfo on the effected host while the naughty peers are connected and send me the diff with whatever changes you're running?

Nothing?  Outbound and inbound connections do not compete with each other. You will still be limited in the number of outbound connections you have to a single /16.

Can you clarify what you mean by "the seed nodes". Do you mean DNS seeds?  Returning how? Need more details!

Edit: Okay, I see seed.bitcoin.sipa.be is returning a single 46.105/16 to me. Is this what you're referring to?

OK, if they don't behave like a normal client behind a NAT that definitely confirms your suspicions. Large scale NAT farms are popping all over the world right now, and many programs tend to go berserk when receiving connections from those.

This message was too old and has been purged

How about another hypothesis: an head-end of a CG-NAT (http://en.wikipedia.org/wiki/Carrier-grade_NAT) device for some large French MVNO (http://en.wikipedia.org/wiki/Mobile_virtual_network_operator) or some similar arrangement like Orange FunSpot (Free WiFi Internet access service).

Also had 1. Blocked it also.

46.105.210.* are addresses managed by OVH, a major french hosting provider.
Usually, OVH provides a bunch of IP addresses with a single server. Very useful for a sybil attack...
These nodes seem active since a few months (see this post).

EDIT: Just checked my full node (hosted by OVH  ) and I've found 1 ip from this subnetwork (among 56 connections)

Also (dns) seed nodes are only rarely used.  Maybe on a brand new bitcoin installation.  On restart it should revert to the peers.dat.  This file contains data on peers your node has previously seen/connected to.  On restart bitcoin should try and connect to these. You should check whether your outgoing connections are also just from this subnet.  Incoming I understand.  But outgoing should be fine.

This is my lay understanding of how it works.  Seems there is something wrong at your end.

This message was too old and has been purged

That is pretty weird behavior. Just checked my nodes and each had only one connection to that subnet ( as expected).
I blocked it anyway, but I'm curious whats going on in your case.
What version of bitcoin core do you run ?

This message was too old and has been purged

This is already part of bitcoin AFAIK (at least for outgoing connections and over /16).