Topic: New Paper: Deanonymisation of clients in Bitcoin P2P network (Read 7996 times)

Excellent!

I've been accused in the past of "not caring about privacy" -- when I do care a lot about privacy. But I am not a privacy researcher, and I have a deep respect for how difficult it is to create a truly privacy-preserving system.

I'm very happy that somebody who is an expert is thinking about, and working on, countermeasures.

We  have conducted a few more experiments to check some parameters of the
attack. First, we tested the stability of  the fingerprint (eight first-hop
connections). We were running our bitcoin client for about 10 hours. During this time 3
nodes out of eight  have disconnected. Analyzing the data from
http://getaddr.bitnodes.io/ we see that after two hours at most one node
would disconnect in average.  So for the typical duration of a client session the
fingerprint is very stable.

The second point we wanted to check was regarding the usage of VPN. Indeed
it will protect user's IP, but we wondered what would happen with the
stability of a fingerprint. I've made a couple  of experiments on the
testnet, connecting to it:
1) via public free VPNs (vpngate.net);
2) via a non-free one (AirVPN).
3) via my own VPN server.

For the cases 2) and 3) the stability of fingerprint was the same as if no
VPN was used.
For the case 1) connections to entry nodes were dropped
from time to time (about every 20 mins for the main net and about every
few minutes for the testnet due too absence of traffic) by the VPN servers.
It's likely that free VPN servers were set with small inactivity timeouts
and some limits for connection durations.

We are currently working on a countermeasure. In particular  we wonder how
reducing from eight to four entry nodes would effect the bitcoin network.
We also think to decay the connections based on the number of transactions
(for example  renewing half of the entry node connections after each
transaction). It might be interesting to include a proof of work for
creation of connections, but this would create a compatibility issue.

I'm sure there's some price at which you'd be happy to serve them the entire chain.

Problem is there is no method via which that can be automatically negotiated in the current network.

We solved this in Gnutella and now Ripple by having peers who receive an IP advertisement originating from a directly connected neighbor perform a "connectivity test" to make sure that the neighbor can accept incoming connections, and only relay the advertisement if the test succeeds. There is some info on Ripple's implementation in the Peerfinder documentation (https://github.com/ripple/rippled/tree/develop/src/ripple/peerfinder#livecache) and source code.

Ripple's connection strategy also strongly preferences peers to which it has had success connecting to in the past (https://github.com/ripple/rippled/tree/develop/src/ripple/peerfinder#bootcache)

By "new" I mean manufactured sometime in the last decade.

Most new routers today maybe, most routers out in the field however are likely not very new at all.

I have for example blocked Bitcoin from incoming connections, 8 are more than enough for just keeping up with the block chain and my upload is too slow to be useful to others. I'll change this depending on how the implementation of header-first-sync is going to look like. If I can enforce a ban on older protocol versions, I'll likely enable inbound transactions again, since people loading single blocks or just headers are fine with me - people trying to load the whole chain are not.

I am surprised that the percentage of "outbound only" nodes is so high.  Bitcoin takes advantage of UPnP.  This can be disabled either in the client or in the router, but today most routers ship with UPnp support enabled.   This behavior can be disabled by the user (either in the client or in the router) but any user sophisticated enough to do that would probably do port forwarding (more connections is always better in a trustless peer network). So my assumption was that most nodes (even those behind a NAT/FW) should be addressable.

What's the correct one mean?

Greek

pseudo- = wrong/false in greek, ano- = none/without (nym = name)

pseudo anonymity would be "false" anonymity or "falsely without name".

Source?

Pseudonymous != pseudo anonymous.

Bitcoin is only pseudo anonymous

There's many ways to link your identity

Might be also a bit problematic - while it may be doable (just like that website that crawled Twitter for people announcing to go on holidays/checking in for flights and then marking their homes on Google Maps), it might not be legal to do it widespread. Also there are certain costs involved with running such infrastructure and hosting that information, so you either have to sell the info or rely on ads/donations.

Especially large services like blockchain.info have VERY likely a good chance to link IPs to enough addresses to make deanonymizing the remaining few feasible.

Ok, 5 years+ and nothing, thats good "news". Of Course it doesn't mean its not done, if gov agencies or suchs have done it they most likely will not post about it. Having seen so many other hacks in the it-world and the subsequent show of, its still a good sign.

True but my Coinbase where I buy is fucked

That really depends on if you use several layers of VPN, and on if you use offline wallets 

Your online wallets and exchanges know your ip tho

There are no examples. And even if, it would be an exception rather than the rule

No

Are there any example where one known identity has managed to link a bitcoin address to a physical address - and made the whole thing publicly available ?