Bitcoin Forum
March 19, 2024, 02:07:29 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 6 »  All
  Print  
Author Topic: This message was too old and has been purged  (Read 37825 times)
Evil-Knievel (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
March 06, 2015, 07:19:08 AM
Last edit: April 17, 2016, 07:51:21 PM by Evil-Knievel
 #1

This message was too old and has been purged
1710814049
Hero Member
*
Offline Offline

Posts: 1710814049

View Profile Personal Message (Offline)

Ignore
1710814049
Reply with quote  #2

1710814049
Report to moderator
1710814049
Hero Member
*
Offline Offline

Posts: 1710814049

View Profile Personal Message (Offline)

Ignore
1710814049
Reply with quote  #2

1710814049
Report to moderator
1710814049
Hero Member
*
Offline Offline

Posts: 1710814049

View Profile Personal Message (Offline)

Ignore
1710814049
Reply with quote  #2

1710814049
Report to moderator
Every time a block is mined, a certain amount of BTC (called the subsidy) is created out of thin air and given to the miner. The subsidy halves every four years and will reach 0 in about 130 years.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Evil-Knievel (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
March 06, 2015, 07:53:01 AM
Last edit: April 17, 2016, 07:51:14 PM by Evil-Knievel
 #2

This message was too old and has been purged
spin
Sr. Member
****
Offline Offline

Activity: 362
Merit: 258


View Profile
March 06, 2015, 08:35:09 AM
 #3


EDIT: My suggestion would be to go the same way as it is implemented in tor's circuit building algorithm,
and disallow multiple connections to IP addresses on the same /24 subnet.


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

If you liked this post buy me a beer.  Beers are quite cheap where I live!
bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
Evil-Knievel (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
March 06, 2015, 08:41:10 AM
Last edit: April 17, 2016, 07:50:59 PM by Evil-Knievel
 #4

This message was too old and has been purged
goregrind
Full Member
***
Offline Offline

Activity: 149
Merit: 100


View Profile
March 06, 2015, 09:11:24 AM
 #5

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 ?

woot?
Evil-Knievel (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
March 06, 2015, 10:03:28 AM
Last edit: April 17, 2016, 07:50:51 PM by Evil-Knievel
 #6

This message was too old and has been purged
spin
Sr. Member
****
Offline Offline

Activity: 362
Merit: 258


View Profile
March 06, 2015, 10:06:11 AM
 #7


EDIT: My suggestion would be to go the same way as it is implemented in tor's circuit building algorithm,
and disallow multiple connections to IP addresses on the same /24 subnet.


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

We should identify the portions of the code, that do this.
What happens when the seed nodes only return IPs from one /16 subnet? Will it connect anyway or will it refuse service?
What happens if a malicious node is connected "outbound", then It disconnects itself, adds an inbound connection from itself, and uses "GETADDRS" to create a subsequent connection to the same subnet? This way it could slowly fill the connection list with inbound connections from itself?

Not sure what is going on there, but at least my bitcoin node somehow keeps ending up with connections only with 46.105.X.X.

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.

If you liked this post buy me a beer.  Beers are quite cheap where I live!
bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
laurentmt
Sr. Member
****
Offline Offline

Activity: 384
Merit: 258


View Profile
March 06, 2015, 02:54:47 PM
 #8

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  Cheesy) and I've found 1 ip from this subnetwork (among 56 connections)
spin
Sr. Member
****
Offline Offline

Activity: 362
Merit: 258


View Profile
March 06, 2015, 08:53:26 PM
 #9

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  Cheesy) and I've found 1 ip from this subnetwork (among 56 connections)
Also had 1. Blocked it also.

If you liked this post buy me a beer.  Beers are quite cheap where I live!
bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1060



View Profile
March 06, 2015, 11:59:14 PM
 #10

This, on the first sight, looks to me as a large scale monitoring of the bitcoin network.
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).

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Evil-Knievel (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
March 07, 2015, 12:00:45 AM
Last edit: April 17, 2016, 07:49:11 PM by Evil-Knievel
 #11

This message was too old and has been purged
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1060



View Profile
March 07, 2015, 12:40:19 AM
 #12

Yeah, but this would not explain why those nodes are neither relaying TX, nor replying to BitcoinPing messages, ...
Seems they save bandwith aggressively and prepare for something bigger.
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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
March 07, 2015, 12:41:55 AM
Last edit: March 13, 2015, 06:46:03 AM by gmaxwell
 #13

What I noticed is, that the seed nodes (from time to time) return dozens of bitcoin addresses from the same subnet (from france).
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?
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
March 07, 2015, 01:26:52 AM
 #14

Latest Bitcoin Core with 2000 connections allowed
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?

Quote
What happens if a malicious node is connected "outbound", then It disconnects itself, adds an inbound connection from itself, and uses "GETADDRS" to create a subsequent connection to the same subnet? This way it could slowly fill the connection list with inbound connections from itself?
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.
laurentmt
Sr. Member
****
Offline Offline

Activity: 384
Merit: 258


View Profile
March 07, 2015, 02:54:22 AM
 #15

This, on the first sight, looks to me as a large scale monitoring of the bitcoin network.
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).

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.
Evil-Knievel (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
March 07, 2015, 10:29:47 AM
Last edit: April 17, 2016, 07:48:58 PM by Evil-Knievel
 #16

This message was too old and has been purged
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
March 07, 2015, 10:59:52 AM
Last edit: March 13, 2015, 08:59:06 AM by gmaxwell
 #17

well I have a maximum of 3100 file descriptors on my system.
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.

Quote
maybe some session hijacking method is used to set up a connection from an unsuspicious (but also malicious) node and then taking it over by one of the 40.xxx nodes with some TCP session hijacking method.
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. Smiley


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.
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1060



View Profile
March 07, 2015, 09:27:46 PM
 #18

Or maybe some kind of NAT problem is going on (i am on a full cone NAT here). Or maybe this is all stupid what I am talking about. I will double check shortly.
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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Cryptowatch.com
Full Member
***
Offline Offline

Activity: 196
Merit: 101


View Profile WWW
March 13, 2015, 01:14:32 AM
 #19

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.
onemorexmr
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250



View Profile
March 13, 2015, 01:17:51 AM
 #20

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





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....

XMR || Monero || monerodice.net || xmr.to || mymonero.com || openalias.org || you think bitcoin is fungible? watch this
Pages: [1] 2 3 4 5 6 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!