Pages:
Author

Topic: "BlitCoin": "unmasks one or both ends of a BitCoin transaction"? (Read 7864 times)

donator
Activity: 1617
Merit: 1012
I know this is an old thread, but i just started looking into this right now.
There is also this (master's degree dissertation) project:
Koshy, Diana. An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. Diss. The Pennsylvania State University, 2013
http://fc14.ifca.ai/papers/fc14_submission_71.pdf

Does anyone know of similar projects/papers?


Sarah Meiklejohn's paper:

https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf
aws
full member
Activity: 219
Merit: 100
I know this is an old thread, but i just started looking into this right now.
There is also this (master's degree dissertation) project:
Koshy, Diana. An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. Diss. The Pennsylvania State University, 2013
http://fc14.ifca.ai/papers/fc14_submission_71.pdf

Does anyone know of similar projects/papers?
member
Activity: 89
Merit: 10
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 a proof of concept/platform for creating transactions using plain text/files/QR codes using the BitcoinJ client. The transaction can be forwarded from a relay client, which could be anywhere with an internet connection. I've been working on it in my spare time for the last couple of months and I've hinted at it on the forums every once in a while. The actual transacting is a bit light on testing and it needs more work on the receiver/relay side. Some of the bigger issues I haven't even begun to address are double spends attempts (accidental or intentional), transaction revocation, and other fun stuff I probably haven't thought of yet. I've been spending the last few weeks setting up tools in preparation of opening up development and doing an initial public release. Look out for in the coming weeks/months.
sr. member
Activity: 308
Merit: 250
Couldn't you probe for an IP of a particular address by sending a small sum of BTC?

Only if they did something with it (ie, spend it on to another address), and then only maybe.
full member
Activity: 126
Merit: 100
Couldn't you probe for an IP of a particular address by sending a small sum of BTC?
hero member
Activity: 910
Merit: 1005
Just to confirm my own code changes...Are you logging the ip from the 'inv' or the 'tx' message?  I originally logged the 'tx', but realized that the 'inv' message comes first. Smiley

--E

Logging from "tx", i think your right it might be better to log from inv (although when the client asks for an inv item the response will come from the same node).
newbie
Activity: 35
Merit: 0
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.

Just to confirm my own code changes...Are you logging the ip from the 'inv' or the 'tx' message?  I originally logged the 'tx', but realized that the 'inv' message comes first. Smiley

--E
newbie
Activity: 35
Merit: 0
I can easily get 400 connections with a simple setup and some minor code changes.  How many people would need to have the same setup and then pool the data to have 90% confidence that they know the ip address of the initial transaction?  Is that even possible?

Suppose there were 'n' computers with this setup, each with ~400 connections that log the time they first see a transaction.  The one 'n' computer that saw the transaction first would most likely know the originating ip.

Alternatively, Could/Would you have to map out the network (i.e. know who is connected to whom) to figure it out?

I agree that once a client has 8 connections it won't connect again, but I believe that disconnections are fairly common.  Just check the 'debug.log' file in your bitcoin client data directory and look for 'disconnecting node'.

--E

hero member
Activity: 910
Merit: 1005
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.
sr. member
Activity: 308
Merit: 250
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.
legendary
Activity: 1400
Merit: 1005
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.
sr. member
Activity: 332
Merit: 250
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.
newbie
Activity: 35
Merit: 0
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
hero member
Activity: 504
Merit: 504
PGP OTC WOT: EB7FCE3D
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
newbie
Activity: 30
Merit: 0
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?
legendary
Activity: 1400
Merit: 1005
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?
newbie
Activity: 35
Merit: 0
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
sr. member
Activity: 332
Merit: 250
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?
legendary
Activity: 1596
Merit: 1100
That is definitely an area in need of improvement:  we are always desperately short of hosts that accept incoming connections on the network.
legendary
Activity: 2408
Merit: 1121
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.
Pages:
Jump to: