"BlitCoin": "unmasks one or both ends of a BitCoin transaction"?

[netrin]

If peers exchanged session keys (pki or diffie-h-m), then users could onion-wrap their transactions just like nym/cypherpunk remailers. If nodes broadcast transactions at random or frequent intervals I think it would be very difficult to associate a single ip with a transaction, like TOR-lite implemented in the bitcoin network itself.

[1713868702]

1713868702

[1713868702]

1713868702

[1713868702]

1713868702

[1713868702]

1713868702

[cbeast]

"Dan’s two main assertions are that Bitcoin is not scalable (at transaction levels reaching even a fraction of those for the Visa payment network)"

Does this mean we can make Visa payments for a fraction of a cent? I don't agree with Dan's comparison's of bitcoin to Visa. A more interesting argument would be in how Visa would benefit from decentralization.

[Serith]

so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin
address.

Blitcoin? (Black Hat 2011)

how about an obvious solution to have proxy settings as an option for bitcoin client?

[EhVedadoOAnonimato]

This just highlights the importance of hiding your IP when using bitcoin. The use of Tor should be a "recommended practice" as the use of different address per transaction. It would be nice to provide a bitcoin+Tor bundle on bitcoin.org.

Unfortunately I'm not sure if the current bootstrap process could handle most nodes being behind Tor or I2P. Bitcoin should be capable to connect to URLs instead of only IPs (is it? I'm not sure), so that hidden services could be resolved. And it would be nice if every bitcoin node, bundled with the anonymization proxy, could set up a hidden service for itself automatically.

[apetersson]

i don't know who came up with this "bitcoin is anonymous" thing.
it is clearly not, anyone who knows about graphs, read the paper or looked at blockexplorer can tell you that. so please stop beating a dead horse

that does not mean it is useless. in fact, its non-anonymity legitimizes it when looked at by governments. embrace it.

[EhVedadoOAnonimato]

i don't know who came up with this "bitcoin is anonymous" thing.
it is clearly not, anyone who knows about graphs, read the paper or looked at blockexplorer can tell you that. so please stop beating a dead horse

Right... how much bitcoins do I have then, if I have any? Point any transactions done by me, or prove I haven't ever done any.

Bitcoins do have a good level of anonymity, and if you use it properly, they are much more anonymous than any other electronic means of payment I'm aware of.
 

that does not mean it is useless. in fact, its non-anonymity legitimizes it when looked at by governments. embrace it.

The easier it gets to trace bitcoins transactions, the easier it will be for governments to pursuit those who use the technology. Don't be naive, most governments will try to ban bitcoin if it ever grows enough to bothers them. Actually, I imagine many governments already have laws that implicitly forbid things like bitcoin.

Helping people to preserve their financial privacy is important, and I think it's the second most important utility of bitcoin, after fighting inflation, of course. Actually, I think you cannot do the latter if you can't do the former.

[makomk]

I really like the descriptions of Bitcoin scalability in your other set of slides; they fairly succinctly point out the issues with scaling, and how the proposed solution to dealing with large transaction volumes inevitably mean Bitcoin will become highly centralized.

Edit: Also, now I've found the correct set of slides - how would bitcoinfs by injecting data into other users' transactions work? The signature obviously can't sign itself, but the rest of the transaction script is signed - you'd have to somehow inject data into the signature value itself. Which I guess might be doable actually...

(Oh - and the suggestion of generating private keys from passwords is interesting, because Bitcoin users are obviously already using a less secure version of this using a single round of SHA256.)

[BitVapes]

I really like the descriptions of Bitcoin scalability in your other set of slides; they fairly succinctly point out the issues with scaling, and how the proposed solution to dealing with large transaction volumes inevitably mean Bitcoin will become highly centralized.

who knows, maybe we will all have 900 Petabit/sec connections by the time bitcoin transactions require 1 Terabit/sec.  One can hope.

[TraderTimm]

The major flaw in making any of this works assumes the coins will be spent or transferred immediately. They could just as easily be 'parked' for quite some time until things cool down.

[jgarzik]

That is definitely an area in need of improvement:  we are always desperately short of hosts that accept incoming connections on the network.

[Big Time Coin]

Heh all.

Slides are up at dankaminsky.com/bo2k11.

"What type of transactions are we talking about here? Would you need to actually spend BTC to reveal information? "

Loose transactions that involve sending money, can expose the IP address of the sender.  The transaction has to enter the relay network somehow, and the first sender is the source.

"I was kind of hoping for something a little more interesting, giving his penchant for breaking shit - but this is neat too."

No need to overcomplicate things.  Although, looking at the source, each peer node that is selected from the outbound lists has to be on a unique /16 network.  Getting large numbers of nodes with inbound connectivity and unique x.y.0.0 addresses is actually a bit of a task.  I have a little more interesting plan for how to achieve that inexpensively.

That's great Dan.  Nice work.  Most of the stolen coins can be traced with your technique when they get moved around.  At the very least we can see when they are NOT being moved around, which is also useful information.  It would be nice to put it to work right away because hackers may be dumping mass coins as I type this.

How soon can we mirror blockexplorer.com enhanced with the IPs listed next to the send and recieve addresses in other words how much would you estimate the cost/man-hour investment?  Is this a one-man one-day job or are we talking 10 guys full time for a month.

Once the software is coded up and running smooth, how much would it cost to run your proposed monitoring network 24/7?  Can it be run on a single top-end desktop PC or would it take a huge hardware rental/investment - and what kind of bandwidth?

Just ballpark estimate, can this be done for under $10k and by the end of the month?

[Economics]

This seems pretty simple, but I'm not sure what it takes to scale it.  I modified the standard linux bitcoind client to connect to as many clients as possible and write a line to the log file for each new transaction received.

With my home connection and a mediocre machine, I'm at 375 connections.  What would it take to get more?  Just wait longer; it still seems to grow slowly?  Connect to all irc channels (00-99) to listen for more new connections?  What else could be done?

Below is a sample of the log file (with ip obfuscated slightly).  I could imagine that if you could combine this type of data with blockexplorer, you could get a percentage confidence that a particular ip initiated the transaction.

ip, transaction id, number of connections, time, time with ms
======================================
New tx from,*.*.79.142,   1a1d4f099b2bb9ec3121f99d1efd2ffccd31aad72dbab5528f7fccb868fe581f,   372,   1315497415,   1315497415632
New tx from,*.*.112.255,389557dc8d0d1a55210a324fec4d96af5aa6718ced5dd02ac7227f18d35bbecb,374,1315497444,1315497444126
New tx from,*.*.44.152,d066924c72b5ce47a3fdeae61b7ce684e32ae67de260d4e62097ab701e62d603,372,1315497447,1315497447440
New tx from,*.*.186.54,3c204aa513e940642e7ad07a1b07265d22fb063001b4721d51f270abf457f358,373,1315497451,1315497451284
New tx from,*.*.162.247,b21ee08eb268313a660ce65771b24f16f5b213bc5ee87f692559d783abd41362,376,1315497469,1315497469097
New tx from,*.*.48.11,15cc9d11d658b7239036e119fc2bc9a4959fc686609a44c05b2c7603612657c0,376,1315497469,1315497469939
New tx from,*.*.164.43,24cdfeacc2de0ef849aaa490a22b5f44f5faeb3a20c4c979c894d05f5fd7a688,376,1315497472,1315497472182
New tx from,*.*.119.238,bbbb7ff8aebcff5e5a71f735dfe26217f1930cc6ea8f3f9f3818624317e1d2b7,379,1315497494,1315497494491
New tx from,*.*.75.41,1b261310e0915e2b29fa7a5c24d5188d827da2eeab1480956606e9ddd9b23728,380,1315497516,1315497516919
New tx from,*.*.24.189,bd480e84e14988389bdf6b3de0cf99afc3b53b6be0934e5d5c87596d911bf056,380,1315497517,1315497517998

--E

[SgtSpike]

So let's talk about how to get around this problem, besides using tor (since it is notoriously slow, I can't see it being very suitable for downloading the blockchain through, etc).

What about generating transactions offline, then sending them from a public location, or uploading them to a website, etc?  Is there a way to do this?

[burlyman007]

This is super interesting.

Thank you, dakami, for the find! I enjoyed your slides.

Is there a way to configure my Bitcoin client to run through Tor? Although I don't expect anyone to attempt to trace any of my addresses, I'm all about privacy and security.

Lastly, would generating a new address for each transaction eliminate this security risk?

[Binford 6100]

So let's talk about how to get around this problem, besides using tor (since it is notoriously slow, I can't see it being very suitable for downloading the blockchain through, etc).

What about generating transactions offline, then sending them from a public location, or uploading them to a website, etc?  Is there a way to do this?

I have half a solution: spend coins via tor (broadcasting tx)
and download blockchain as usual, no need to cripple your bitcoin experience

[Economics]

Bitcoin can use a socks4 proxy, so presumably you could easily set a proxy once the blockchain is downloaded.
In fact, there may be a market for a 'bitcoin proxy' that promises some sort of anonymity.  With a large enough user base, this would be feasible.

--E

[Big Time Coin]

The thread lives!!

Remember "Economics", according to the slides, those IP addresses are not the ones initiating the transactions in (100% - 375/~50000) of cases, since those IPs are just gossiping nodes, relaying information received via P2P. 

To get the IP by your technique, you would need to connect to every node.  And since only 8 connections are allowed per node, and once it propogates to 8 it doesn't disconnect itself with no reason, that part of kaminsky's technique (described on slide 25) will not actually work IRL.  Node discovery and nat/tor problems as well.  Also the outbound/inbound allowed thing.

slides @ http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 see slide 22 - 35.

[SgtSpike]

The thread lives!!

Remember "Economics", according to the slides, those IP addresses are not the ones initiating the transactions in (100% - 375/~50000) of cases, since those IPs are just gossiping nodes, relaying information received via P2P. 

To get the IP by your technique, you would need to connect to every node.  And since only 8 connections are allowed per node, and once it propogates to 8 it doesn't disconnect itself with no reason, that part of kaminsky's technique (described on slide 25) will not actually work IRL.  Node discovery and nat/tor problems as well.  Also the outbound/inbound allowed thing.

slides @ http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 see slide 22 - 35.

Actually, that's a good point.  You wouldn't be able to connect to existing nodes that limit themselves to 8 connections, as they already have 8 valid nodes to connect to, and won't change without reason.

[elggawf]

Actually, that's a good point.  You wouldn't be able to connect to existing nodes that limit themselves to 8 connections, as they already have 8 valid nodes to connect to, and won't change without reason.

Okay, so you can't do the attack on demand. You could, however, trivially and for very little cost, maintain a good number of peers accepting incoming connections, and just wait it out until you're pretty sure you're connected to most of the peers on the network. That's (I think) what jgarzik is talking about how we always need more peers accepting incoming connections, because the less there are, the easier and less costly this attack is.

[piuk]

I've started recording ip's on my block tracker site. Currently connected to 600 nodes but don't want to increase the limit any further as bitcoind cpu usages gets too high.

http://pi.uk.com/bitcoin/unconfirmed-transactions

It will be interesting to to see whether any of these ip's are actually the transaction sender. A lot of them link to personal home pages and stuff.

When i collect enough data i'll use the frequencies of ip's associated with a given address to try and guess the owner.