This message was too old and has been purged

[Cryptowatch.com]

the question is what you use the data for...i have no doubt that your intentions are honest btw.

Here's your answer as to what the data was used for:
https://bitcointalk.org/index.php?topic=978088.msg10756505#msg10756505

I don't have an issue with people not trusting me, is not that what the world has come to? I just repeat that the only reason I did nmap on that host was because I found some of the same ip's; 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 in the debug.log of my bitcoind, upon reading OP I did the investigation as you can see in the link above. The intention was to find out what & who was behind the monitoring on the network. If you want to label me, then give me the whitehat label please, I really have no further to add to this particular question.

[1713453443]

1713453443

[1713453443]

1713453443

[onemorexmr]

the question is what you use the data for...i have no doubt that your intentions are honest btw.

Here's your answer as to what the data was used for:
https://bitcointalk.org/index.php?topic=978088.msg10756505#msg10756505

I don't have an issue with people not trusting me, is not that what the world has come to? I just repeat that the only reason I did nmap on that host was because I found some of the same ip's; 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 in the debug.log of my bitcoind, upon reading OP I did the investigation as you can see in the link above. The intention was to find out what & who was behind the monitoring on the network. If you want to label me, then give me the whitehat label please, I really have no further to add to this particular question.

sorry (blame my english) i did not question your intention (i already knew it). it was more in the line of "its the question what the guy nmapping other people has for intentions"

IMHO: it is easy to use iptables and a small script to autoblock anyone who is nmapping... so i just dont understand people yelling when someone does it.

btw "I don't have an issue with people not trusting me, is not that what the world has come to?"
sadly...yes...

[Cryptowatch.com]

http://insidebitcoins.com/news/someone-may-be-deanonymizing-your-bitcoin-transactions/30759


Maxwell has pointed out that there has been some slow progress in the prevention of sybil attacks recently, but he seemed more concerns with the general attitude of the bitcoin development community as a whole. He stated that interest in implementing better protections against sybil attacks has been “pretty low” outside of the core developers, and he also described his disappointment with “how few people realize how important privacy and fungibility is for bitcoin’s viability as a currency.”

A blessing in disguise

At the end of the day, this event should be viewed as a reminder that bitcoin transactions are not anonymous and far from private by default. The reality is there is still plenty of work to be done in the realm of protecting privacy in bitcoin. Getting angry at how anyone interacts with the bitcoin network is useless; it’s the base incentive structure that matters. If there are any weak spots in the protocol, it will only be a matter of time before someone tries to exploit them. Instead of yelling at the attackers, it would probably make more sense to build better defenses. When there are weaknesses in a decentralized system, there is no point in hoping that everyone will just play nice.

[theskillzdatklls]

this is why we cant have nice things

[cr1776]

this is why we cant have nice things

There were two from that IP range that were attached to my node. 

[colinistheman]

"If there are any weak spots in the protocol, it will only be a matter of time before someone tries to exploit them. Instead of yelling at the attackers, it would probably make more sense to build better defenses."

Quoted from: http://insidebitcoins.com/news/someone-may-be-deanonymizing-your-bitcoin-transactions/30759

I think it's the perfect summary and answer to this thread.

[Ragnarokdel]

is there a way to block certain ip in bitcoin.conf file?

You really want to use iptables (assuming you are on Linux and I cannot imagine why you would not be.) That way you never have to shut down the Daemon just to block an address.

Hmmm... let me think of a single reason... Because I'm a gamer?

[laurentmt]

"If there are any weak spots in the protocol, it will only be a matter of time before someone tries to exploit them. Instead of yelling at the attackers, it would probably make more sense to build better defenses."

Quoted from: http://insidebitcoins.com/news/someone-may-be-deanonymizing-your-bitcoin-transactions/30759

I think it's the perfect summary and answer to this thread.

Yep ! Actually we should even thank these guys because this "attack" is quite cheap: use of IP addresses in the same subdomain isn't really smart for a sybil attack 
I may be wrong but it's likely that similar attackers are still acting undetected because they can afford a better strategy (different ip ranges, imitation of full nodes behaviors, ...).

[cr1776]

"If there are any weak spots in the protocol, it will only be a matter of time before someone tries to exploit them. Instead of yelling at the attackers, it would probably make more sense to build better defenses."

Quoted from: http://insidebitcoins.com/news/someone-may-be-deanonymizing-your-bitcoin-transactions/30759

I think it's the perfect summary and answer to this thread.

Yep ! Actually we should even thank these guys because this "attack" is quite cheap: use of IP addresses in the same subdomain isn't really smart for a sybil attack 
I may be wrong but it's likely that similar attackers are still acting undetected because they can afford a better strategy (different ip ranges, imitation of full nodes behaviors, ...).

With IPv6 this type of attack will become even more difficult to detect and prevent merely by blocking the IPs.

[Rassah]

In before conspiracy theories come out:

Chainalasys VS Mycelium - The full story


Mycelium Wallets use our own custom nodes to process the bitcoin blockchain and scan for address balances. These nodes were written by Jan Møller while he was the Lead Developer, along with our other devs. The job of these nodes is to parse the 30 gig Blockchain database into our own custom database, which is much larger, being over 100 gigs in size, but which allows for very quick and easy lookup of address balances, allowing for instant balance lookups and to do things like Cold Storage spending from paper wallets and Trezor.

Mycelium's owner and developers believe in total financial privacy and personal freedom, and our company has a goal to make Mycelium Wallet the most anonymous wallet possible. For this reason, we have kept our wallet code completely open since the beginning, and have been public and open about what goes on internally in our company (I hope you have noticed my frequent updates, especially with the unfortunate Entropy delays). And even while Jan was still the lead dev, we have created LocalTrader to work completely anonymously, using only bitcoin signed messages for user authentication and encrypting all user chat P2P using their respective private keys so our servers receive no usable data. We have also added HD wallet support, and disabled all IP and transaction logging on our nodes. However, we also realize that just us claiming that we do that isn't good enough, and that's why we added full Tor support, and are in the process of implementing CoinJoin, which we hope to have enabled by default, so that even those who don't care about staying anonymous will help contribute. Our goal was to have Mycelium Wallet be as anonymous as Dark Wallet, and that has not changed.

Jan Møller, our lead developer who did most of the work on the nodes, realized that the node-parsed blockchain database can be used to analyze bitcoin transaction activity, and help track transactions in the same way that our current financial institutions do (although with much less certainty). So he decided to have his own project that does just that, and has split off from Mycelium company last October. We still kept him on as our chief technical consultant, since he did write most of the node and original wallet code, so he is technically still employed by Mycelium, but he has had no access to our nodes since he left. Our current full time lead developer is Andreas Petersson, who is working on implementing Coinapult Locks right now, and the other two developers are Jan Dreske (/u/trasla here) and Daniel Weigl, who have been adding support for Trezor, fixing bugs, adding minor requested features, etc.

We at Mycelium are not fans of what Chainalysis does, but we can't really object too much, because if something like this is even possible to do, then someone will do it, whether it's Jan's company or someone else. It's also preferable that this is done by a public company in the open, instead of in secret by a government agency. And secondly, since the developer behind this is someone who worked with us, we can at least get inside knowledge of what may be tracked and how by such systems, so we can be aware of what to watch out for and what to fix. Obviously it's not a guarantee that we will get an honest answer, but it's still better than nothing.

With regards to why our website's About section still lists Jan Møller as a Lead Developer, it's because our website dev has been working full time on another (secret) Mycelium project, and has not had the chance to change anything. I guess the site is too low of a priority to update. Note that both of our current top wallet developers who have been doing most of the work these past few months, Jan Dreske and Daniel Weigl, are completely missing from there too. I am sorry that I have not publicly stated anything about this either, but since Chainalysis is a completely separate company, Jan Møller has not had access to our internal systems since he became a consultant, and our internal goals are still total anonymity, there was no risk whatsoever to Mycelium or the privacy of our users from the Mycelium side. I have been fairly open about being an AnarchoCapitalist myself, supporting people like Cody Wilson and Ross Ulbricht, and supporting the idea of The four pillars of a decentralized society as explained by Johann Gevers to help decentralize government functions. So if there ever is a risk of Mycelium becoming a snooping agency, or if Mycelium changes its goals with regards to expanding personal freedom, I still promise to let the community know, sine there would be no way I would be willing to continue to work there if that happens.

[sandor111]

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?

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.

Hi gmaxwell,

well I have a maximum of 3100 file descriptors on my system.

Code:

anonymous@anonymous-desktop ~/Development/counterparty-gui $ ulimit -n
3100

I will try to recreate the setting and do a getpeerinfo dump. I will also set up an IDS, 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. As both nodes are cooperating and share sequence numbers this should not be too hard. 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.

It's not possible to have over ~864 (?) connections, or absolute max is 1024 (FD_SETSIZE) without changing the netcode extensively. Personally for fun I have coded an epoll implementation for the bitcoin core to allow an arbirary number of connections, I got up to 6k connections before the CPU maxed out due to the inv flooding.

[justusranvier]

Based on my legal studies at the University of Wikipedia, I think Chainanalysis is violating the CFAA.

https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act#Criminal_offenses_under_the_Act

Connection slots made available by full nodes are offered to peers who will participate in the relaying of transactions, I doubt the people who run full nodes authorize use of their limited connection slots for the purposes other than participating in the Bitcoin protocol.

[Dargo]

Looks like the people at mycellium and kraken are involved...

Kraken is not in any way "behind" Chainalysis. Michael Gronager left Kraken in October 2014 to work on Chainalysis and has only remained affiliated with Kraken in an advisory role.

[Raize]

I have been fairly open about being an AnarchoCapitalist myself, supporting people like Cody Wilson and Ross Ulbricht, and supporting the idea of The four pillars of a decentralized society as explained by Johann Gevers to help decentralize government functions.

For those unfamiliar:
https://www.youtube.com/watch?v=8oeiOeDq_Nc

[ABISprotocol]

Based on my legal studies at the University of Wikipedia, I think Chainanalysis is violating the CFAA.

https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act#Criminal_offenses_under_the_Act

Connection slots made available by full nodes are offered to peers who will participate in the relaying of transactions, I doubt the people who run full nodes authorize use of their limited connection slots for the purposes other than participating in the Bitcoin protocol.

It may well be that Chainanalysis is violating CFAA, but then again when I get up and breathe in the morning I am probably violating several laws.  

Why not just start going through the process of ensuring they are blocked.

If they continue with their efforts, I recommend this as a resource:

Consider what Mozilla did as a technique against a global spyware provider...
https://blog.mozilla.org/blog/2013/04/30/protecting-our-brand-from-a-global-spyware-provider/

Or, use the courts to seize the domain(s) of Chainanalysis or any other company that does what they are doing via the ex parte TRO process - like this:
http://www.honeynet.org/node/830

Word of warning: I'm not a lawyer, this isn't legal advice.  So if you feel compelled to examine any of these options further, do what any reasonable person must do: Consult a lawyer before doing anything!

Otherwise, block Chainanalysis's shit.

Thanks to those who have caught this early.

[justusranvier]

Based on my legal studies at the University of Wikipedia, I think Chainanalysis is violating the CFAA.

https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act#Criminal_offenses_under_the_Act

Connection slots made available by full nodes are offered to peers who will participate in the relaying of transactions, I doubt the people who run full nodes authorize use of their limited connection slots for the purposes other than participating in the Bitcoin protocol.

It may well be that Chainanalysis is violating CFAA, but then again when I get up and breathe in the morning I am probably violating several laws. 

Why not just start going through the process of ensuring they are blocked.

If they continue with their efforts, I recommend this as a resource:

Consider what Mozilla did as a technique against a global spyware provider...
https://blog.mozilla.org/blog/2013/04/30/protecting-our-brand-from-a-global-spyware-provider/

Or, use the courts to seize the domain name of Chainanalysis or any other company that does what they are doing via the ex parte TRO process - like this:
http://www.honeynet.org/node/830

Word of warning: I'm not a lawyer, this isn't legal advice.  So if you feel compelled to examine any of these options further, do what any reasonable person must do: Consult a lawyer before doing anything!

Otherwise, block Chainanalysis's shit.

Thanks to those who have caught this early.

Blocking them is certainly a great idea, and so is implementing technical measures that make what they are trying to do more difficult or (ideally) impossible.

There's also a very satisfying form of symmetry in holding startups in the regulatory compliance field accountable to regulations which they are violating.

If companies who are disrupting the Bitcoin network for a profit were held accountable to criminal law, then maybe the investors in such companies would apply more scrutiny to the ventures they fund.

[bitpop]

This is exactly what they want you to do. We are attacking a whole subnet, maybe a competitor they wanted gone, testing for the future to maybe take down bitpay or something. If they were real, they'd use random ips.

You really think they'd use one subnet? And make it so obvious? With a homepage playing right into our fears? This whole thing is staged. Bitcoin is already designed to avoid peers from the same subnet. Why would they use that?

Using a node with tor is a bad idea.

[ABISprotocol]

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. 

Even probabilistic data is bad. They could use it for targeted advertising for instance.

Plausible deniability is not the be-all and end-all. Even if they don't know for sure it could be reason enough to put you under further surveillance.

Was it not that a person had all his electronic equipment confiscated and brought in for having a bitcoin-node associated with a rogue transaction displayed on blockchain.info earlier on?

If there are entities paying for analysis of the block chain, and it's acted upon (by law enforcement) data that cannot be fully trusted, it could cause lots of troubles.

Also, while blocking ip's of nefarious nodes is a temporarily solution, it's only an annoyance for the perpetrators, and given they have sufficient resources, they could further hide their activity as to not give away their intentions.

Given they have enough resources, they could even have automated ip-switching going on. Once an ip is blocked by a sufficient number of legit nodes, they just switch the ip of that node, and all of that could be automated. So in essence blocking the IP's are a bit like holding your hand over a hole in your rowing boat that is leaking in water, might give you some temporarily relief, but is not a lasting solution.

Now - it's near impossible to know who really controls a node, if they really want to go stealth. If a node acts like a normal node in all ways, why should it not be considered a normal node?

If I understand it right, the chainalysis mode of operation is for them to connect to as many nodes as possible, so if I do a transaction directly from ip A, which runs a full bitcoin core node, be it on a cable-connection or otherwise, if cainalysis is connected to the node where the tx is orginating, the ip-address of the node where the transaction was orginating is recorded within the chainalysis database. They will probably use many other sources to get more info about the owner of that ip-address. If they're only a private company they will have less data points to work with, but if they're an intel agency, there's virtually no limit as to how sophisticated the systems could be, in theory they could plugin directly to the customer database of ISP's and have names displayed in real time in association with the IP's. Information that could further be relayed and shared with relevant parties.

Bitcoin is only pseudonymous, as everyone can lock up a transaction in the block-chain, and I assume network analysis cannot be prevented, but I do think it should be made more difficult.

But a blacklist solution is dangerous. Who's to decide what goes on the blacklist, and who's to verify the decisions are correct? Perhaps some automated solution in bitcoin core where peers that's behaving unexpectedly could be automatically banned is a better solution? But again, that's much like holding hand over leaking hole, as if certain footprints reveals rogue nodes, they will only change their appearance to appear more legitimate. And I'm not sure, but I believe bitcoin traffic is unencrypted in transit, so what prevents an intel org from manipulating the traffic (making legit nodes appear rogue), in essence grinding the entire network to a halt if nodes automatically ban misbehaving nodes?

I'm no TOR expert, but I've noticed there's been much mumbling about TOR not being all that secure anymore, so would a normal user really be more secure if he used Bitcoin+TOR?

Since bitcoin is supposed to be trustless, if we started to make a whitelist of legit nodes, that would go against that ideal.

So, in reality, how do we ensure that most nodes on the network are legit, and what's the best method of blocking rogue nodes from connecting to your own node?

In my view, in essence it boils down to freedom and privacy. There's something fundamentally wrong when certain people need to exert "control" over others against their will.

On the TOR point specifically, numerous studies have been done that have revealed problems involving the use of TOR and bitcoin in combination, leading to vulnerabilities that have not yet been mitigated.

See:

https://github.com/OpenBazaar/OpenBazaar/issues/866#issuecomment-62577905

The release of Tails with Tor and Electrum has me concerned due to these issues as were commented on by Biryukov, Pustogarov, and others.

[gmaxwell]

On the TOR point specifically, numerous studies have been done that have revealed problems involving the use of TOR and bitcoin in combination, leading to vulnerabilities that have not yet been mitigated.

Your comment is confused and misleading.

The "problems" reported initially is that an attacker can DOS attack to cause IPv4 nodes to block nodes behind Tor. This is true, but we were always aware of that and implemented hidden service bitcoin nodes as a tool to improve that. The paper was revised to also point out that you could concurrently DOS attack hidden service nodes-- which is generally true with or without tor, but there are not as many HS nodes.

The end result of all that though is just a DOS attack. Maybe if an attack happened, which isn't currently happening, you might have problems getting a new connection after starting your software.  This is completely safe, it might be irritating but your privacy would not be compromised unless you took the affirmative (and obviously foolish) action of disabling Tor support in your wallet.

None of this is a reason to not use Tor-- it's a reason, among _many_, that Tor doesn't solve all possible problems but you lose nothing by using it.  It's harmful to the community for you to promote otherwise.

[ABISprotocol]

On the TOR point specifically, numerous studies have been done that have revealed problems involving the use of TOR and bitcoin in combination, leading to vulnerabilities that have not yet been mitigated.

Your comment is confused and misleading.

The "problems" reported initially is that an attacker can DOS attack to cause IPv4 nodes to block nodes behind Tor. This is true, but we were always aware of that and implemented hidden service bitcoin nodes as a tool to improve that. The paper was revised to also point out that you could concurrently DOS attack hidden service nodes-- which is generally true with or without tor, but there are not as many HS nodes.

The end result of all that though is just a DOS attack. Maybe if an attack happened, which isn't currently happening, you might have problems getting a new connection after starting your software.  This is completely safe, it might be irritating but your privacy would not be compromised unless you took the affirmative (and obviously foolish) action of disabling Tor support in your wallet.

None of this is a reason to not use Tor-- it's a reason, among _many_, that Tor doesn't solve all possible problems but you lose nothing by using it.  It's harmful to the community for you to promote otherwise.

Actually, I use TOR myself.  I just disagree that we should blindly use TOR with bitcoin or suggest that users do the same thing without warning people of the possible consequences.

See in my remarks on github where I suggested one possible option:

"Appropriate warnings for users who are using OpenBazaar (which incorporates bitcoin use) with Tor should be something like this: "Warning: Proceed at your own risk," or, "Warning: Use of Tor and Bitcoin together may result in additional attack vectors that could compromise your privacy. Do you wish to proceed?"

This is not a slam on OB either because I use OpenBazaar.  I simply think it is ridiculous to not warn people of possible risks.