Bitcoin Forum

I've been generating BTC for a week or so now, and I'm enjoying myself very much.

One thing I've been wondering about is the anonymity of the system, and I can't find all the documentation I need to understand.

What I'm wondering about is total anonymity as far as origination of Bitcoins.

The question is analogous to the US government's current laws that any money transferred to terrorists by however long a chain implies criminal liability for the original transferer of the money offshore.

Now, I don't like sending terrorists money at all, whether or not our government approves of them, so I don't wish to do such a thing.

However, as I understand the protocol right now, this sort of chain of payment checking is quite easy in bitcoin land if the bitcoin address scheme is used to transfer money.

Does the IP transfer option mitigate this? My current best practice for completely breaking the chain of who-sent-the-bitcoins-to-whom is:

1) Receiver sets up a listener at 8333 at some IP online, presumably with some tor-based login scheme.
2) Sender, using Tor sends to that IP, say 100 BTC
3) Receiver receives BTC, waits for confirmation from the network.
4) Receiver copies wallet.dat file to real location over Tor
5) Receiver sends money from wallet.dat to 'main' wallet using newly generated Bitcoin address
6) BTC 'laundered'.

Is this the approved method of breaking the chain of payments?

Comments on attacks or other methods?

Just to say, I currently believe based on reading the spec that everyone will know

1) Sender sent 100 BTC to _random_ip
2) Receiver's address sent 100 BTC to 'new_address'

But that these would not otherwise be correlated. Is this correct?

As far as I know, this is incorrect.

Every bitcoin transaction is mapped to a previous transaction. All transactions are signed by the owner of a particular bitcoin address. They are all traceable though the graph. If you think about it, you will realize that otherwise the system would be easy to spoof.

The send to IP address, simply makes a connection there first and asks it for an appropriate bitcoin address to send to. After that everything is the same as any other transaction. That is why there was a warning of a possible man-in-the-middle attack using Tor or other proxies.

(anyone, please correct me if I'm wrong)

Okay.

In that case, I revise my best practices to:

0) use all new bitcoin addresses
1) find a trustworthy bitcoin exchange market
2) transfer in
3) transfer out, if they delete logs
3a) if not, sell bitcoins for USD
3b) transfer out USD
3c) send money to trustworthy bitcoin exchange market
3d) purchase bitcoins

Comments?

I think that the limits of anonymity needs to be discussed if that is going to be a claim of the system.

I'm very interested in that subject, however, others are less so.

Might be worth creating some sort of best practices, depending upon how anonymous you are trying to be.

If you track the progress of a real USD $1 bill, from your pocket and it ends up in the pocket of a terrorist, at what point are you liable?

Using the logic you suggest the US Federal Reserve is the biggest terrorist funder of them all.
(Discussion of whether they are actually deliberately funding terrorists omitted)

Using a bitcoin market will probably not solve the problem you suggest.
And in fact probably makes things worse because it anchors your bitcoin transactions to your real world identity at 2 points. (assuming you're not managing to anonymously buy BTC, in which case that DOES solve your problem and you can just ignore all the steps prior to 3d)

Just only do honest things with your bitcoins and you'll be fine.

Buying things is not dishonest, but that doesn't mean you'll be fine if certain third parties find out.

If you want to stay anonymous, there must be no associations between any of your Bitcoin adresses and anything that identifies you.  That includes your name, address, telephone numbers, IP addresses, friends, enemies, favorite websites, politics and/or whatever.

Doing all that can be inconvenient.  It requires discipline.  You need to keep your identities straight.

There's another issue.  Unless you're going to live in a bunker, you'll need to trust someone.  Even with the bunker, you'll probably need to trust someone.  With Tor, you'll need to trust your exit nodes, to some extent, at least.  Or you'll need to trust your anonymous VPN provider (more than you trust your ISP and/or government, anyway).

I'm still puzzling how to reliably exchange Bitcoins and physical things while maintaining mutual anonymity.  Dead drops either protect sellers or buyers, as I see it.

I started working on a solution to this today. I'll update here when I have some news.

And, for those saying 'just keep your nose clean,' that's entirely not the point.

Regarding the US government, the Patriot Act really did make it much harder to get money outside of the US -- a move that was welcomed by large banks (it pushed small banks out of the international wire business), and the IRS alike. It did it via the mechanism I described. Ask your local banker if they will wire money to Afghanistan for you if you'd like to understand just how hard this is to accomplish in America.

I'm not sure if http://bitcointalk.org/index.php?topic=635.0 (http://bitcointalk.org/index.php?topic=635.0) (a post I just made in a new topic) would help maintain anonymity, but I feel like it can't hurt.  I'd be curious to hear your critique.

Anonymity in BitCoin is really a misnomer. It is really pseudonymity as all transactions are done through bitcoin addresses. An address is equivalent to the pseudonyms used on this site.

When people speak about anonymity/pseudonymity they usually mean link-ability. Can my pseudonym (address) be linked to my real world identity.

However, there is another important aspect, associate-ability. What can others learn about me by watching the behavior of my pseudonym. Because bitcoin is a publicly visible directed graph, link-ability is directly related to associate-ability.

Suppose you use the same handle and anonymous email here, as you do on a kiddie porn site. If that association was made you might be banned here, or even targeted by others. In the real world (and the generalized internet world) those associations are often hard to make. That tends to make people careless. However, in bitcoin these associations are trivial.

Associating your address with a set of behavior gives others a reason to attempt to link it back to you.

Every bitcoin comes to you from someone who knows enough about you to transact with you. When you spend the coins they go to someone who often knows you as well. Each interaction can leak information about you or your behavior.

You would think that single use addresses could protect you, however they can often be correlated easier than you think.

Suppose you want to buy a domain registry from privacyshark for 700 BTC. But you don't want it associated with your well know bitcoin address in your footer here. So you decide to route it through three single use intermediary accounts (x, y, z). So create new accounts X,Y,and Z. Send 700 BTC first to X, then from there to Y, and from Y to Z. Finally you send the 700 BTC on to privacysharks well known address.

Well you are still screwed, because on the bitcoin directed graph, you just drew a straight line from your public address here to privacyshark's public address. Each segment in that line correlates by value amount. They also correlate in time. (one hop each block at worst)

What if you try it differently, you send three different amounts from your public address to the three new addresses. 100 to X, 200 to Y, and 400 to Z. Then you send from X, Y, and Z individually to privacyshark. Well these amounts now create a neat diamond shape on the graph with you at the fork and privacyshark at the join. The transactions to and from X,Y & Z all correlate in time (perhaps even in the same two blocks). They also correlate by amount.

If you already happen to have coins at several addresses and you decide to sent 700 of them at once to privacyshark, I'm not sure exactly how the client generates the transactions but I do know, that they will still correlate by time and amount. Even worse it has the potential to associate non-single use accounts to one individual.

You can only de-correlate the timing by adding more latency. You can only de-correlate the graph connections by adding more hops. You can only de-correlate the values by adding more forking. All of these precautions reduce the utility of bitcoin and increase the complexity of transactions.

Is anyone going to go through all the bother to back-propagate your transaction graph just for buying a domain name? Well they might if privacyshark just registered "kiddieporn.com" and they are looking to link that to the buyer. And while doing that they might happen to correlate the anonymous registry of "IDontPayTaxes.com" with your "trade in bitcoin instead of paying taxes" post here.

By the way, I've got an idea for an automated way of preserving true anonymity in the transaction list. It shouldn't require any changes to the bitcoin system.

I might try to create it as a service if anyone thinks it would be of value.

Other people are going to hate the whole concept though. ;-)

You may like to tell us what it is so we can tell you if we think it will work.

full of win^^^^  This has been bothering me as a purchase proxy merchant.If someone orders a product from a company through me you cant escape the need for a shipping address.How do you get around this glaring traceability?How could you set something up so that there is plausible deniability between myself and my customer in this scenario?

See that's the insidious nature of correlation. If I tell you about it, then build it as a hidden service. The service is forever linked to my user account here!

:-)

I'll post about it in detail but it will take more time to explain than I have now. It involves trust, but in the bitcoin spirit, the trust is cryptologically verifiable. 

To make a truly anonymous payment, the sent address must be not be linkable to a particular person. All addresses belong to a particular key holder. So it's an impasse unless we break the rule about an address belonging to one and only one individual.

So what I'm considering is a automated Tor hidden service that holds the private key wallet for a joint address that anyone can trade through. It would have to be a "trusted" service because obviously anyone with access to the private key could steal everyone's coins. So for the sake of argument, presume that the service is not a scam.

Now an honest anonymity service could provide proof of its honesty using the following automated mechanism.

1. Many users send bitcoins to the anonymizer address in advance like a checking account. Each of these are standard public transaction. That means the service can see who sent the coins and keep private account balances by sending address.
2. Users communicate with the anonymizer through a Tor hidden service so there are no exit nodes that can spy. No one knows where the server is located to avoid other sorts of attacks. There are three messages that can be sent to the service.
2a. Send this transaction.
2b. Get Balance.
2c. Acknowledge Balance.

Send this transaction - takes as parameter a almost-standard transaction sending money from the anonymizer address to any recipient address. The only non-standard part of the transaction is that it is signed by the "account holder" rather than by the anonymizer. The system validates this signature and matches it to the depositors account in the standard way. It then checks the current account balance. If there is sufficient funds, the anonyizer simply removes the account holder's signature, and resigns the transaction and broadcasts it. It then *temporarily* stores the original signed transaction request and updates the account balance.

Get Balance - the message returns the account holder's current private balance and any confirmed account transactions.

Acknowledge Balance - once the account holder has reconciled his "checkbook" against the account records, he then signs his account balance and sends the signature in an acknowledgement message. When the system receives the acknowledgment it deletes the transaction logs and saves the signed balance.


So should any user try to repudiate the anonymizer's honesty the system can show the user's previous signed balance, any signed but unacknowledged withdrawals and any new new deposits (from the transaction log). These should sum to an unassailable current balance.

---

As with any mix-net, the system requires a large number of users to provide anonymity. It doesn't do any good to have a single user anonymity system. It also requires a buffer with some latency. It doesn't do any good to deposit 1234 BTC and then immediately send 1234 BTC to someone else using the system. That can be easily correlated just like in my previous post.

The optimal use would be for lots of users to make regular deposits (like a paycheck). Then they could request payments at will, just like with a checking account.

So to be optimally anonymous all users must:
1. make regular payments
2. have private/hidden balances
3. communicate with the system through a non-observable channel
4. make irregular payments (not matching public deposits)

Anyway, that's the general idea. Feel free to shoot holes in it.

I like that, Red.  And I have a tweak.

As you've noted, your plan is vulnerable to correlation attacks.  That's especially problematic for bitcoins, given that the entire transactional history is available for analysis.  Perhaps that's my market niche  ;)

Anyway, one could further decouple deposits and withdrawals by setting up several such Tor hidden services ("agents").  Agents could trade bitcoins for other digital currencies via exchanges, and trade with other agents only via non-bitcoin currencies.  Each agent would possess an independently-randomized cache of bitcoins.

Each agent would create many virtual Linux machines, each containing a fresh Bitcoin client (VMC).  They'd charge each VMC with bitcoins from their cache.  VMCs are basically bitcoin debit cards.

When you needed to make a payment, you'd request a VMC from your agent containing the necessary balance.  Your agent would request the appropriate VMC from one of its peers, with whom you do no direct business, and deliver it to you anonymously.  None of the bitcoins in that account would have any relationship to you, except by chance.

When you've spent out the VM, you'd just delete it.

And BTW, agents could obviously play standard financial games.  They could pay interest on deposits, make investments and loans, sell shares, trade derivatives and whatever.  And they could do all of that inside Tor (or wherever)  :)

Of course, you have to trust your agent  :(  And perhaps there's a way around that?

"Anonymity" is a vague phrase and we've got to be careful what kind we're talking about.  It might for example mean:

(1)  Not having your name directly on a transaction, but any competent investigator (the attacker) could talk to a merchant who has a database associating your name with certain Bitcoin address(es) and find out that your name controls those address(es). 
(2) Same as (1) but instead of finding out your name they simply geo-locate your address(es) by linking them to your IP address.
(3) Same except instead of name or geo-location they figure out what kind of business you are up to from the detailed history on the Bitcoin chain of which addresses you've transacted with and when. 
(4) They figure out all of (1)-(3).
(5) You try to avoid any of (1)-(4) by trusting intermediaries not to keep logs.
(6) Secure untraceability, which avoids (1)-(5) without having to trusted anybody in particular.   Tor, for example, can mostly achieve this (every relay in chain would have to collude or be simultaneously monitored) for individual encrypted messages.

I only call (6) _secure_ anonymity.   (1)-(5) I am uncomfortable with people advertising as "anonymous" because, although it might not have your name directly in the log, "anonymity" in the crypto community has traditionally meant something much stronger, i.e. secure untraceability.    Computers have perfect memories and are full of obscure caches, and in the financial world intermediaries are often required to keep logs by law, so you should just assume they will remember everything rather than trusting them not to.

I don't know how to make secure anonymity work directly with Bitcoin, since having the transactions be public and related (by chains, by addresses, and by signatures) is part of Bitcoin's security protocol while secure anonymity is about making each transaction unlinkable to the others.   It can be made to work indirectly by having an intermediary issue a different kind of coin, blinded digital cash, and then mixing much as suggested above.    Then if you want to be anonymous you exchange your bitcoins for anonymous cash and if you don't you just use bitcoins directly.     The issuers of anonymous cash can be required by customers to use bitcoins to keep securely auditable reserves so bitcoins would still be adding tremendous value in making the currency more trustworthy even if everybody else is using the anonymous cash instead of bitcoins directly.   This dual setup is very analogous to a bank holding gold reserves and issuing bank notes, except the "gold" in this case, bitcoins, can be made much more securely auditable and much harder to steal.   Since the anonymous cash is blinded each transaction is securely unrelated to the others and one does not have to worry about either the intermediary or the merchants keeping logs or linking your name to a particular transaction.   Because the logs can't be pieced together to link transactions to each other.   Google "blind signature"+"cash", there is a good technical literature out there about how to do securely anonymous digital cash.   I particularly recommend "double blinded" cash as it allows the payee as well as the payer to remain securely anonymous.

I'd appreciate feedback on the following anonymization scheme.

Let's say that I have N Bitcoin clients, all Ubuntu VMs, each with a different stable IP address, distributed globally via secure VPNs.  The VMs are themselves interconnected by secure VPNs.  There's a script running on each VM that polls the Bitcoin balances and receiving addresses of all the other VMs.  Whenever a client receives Bitcoin, it sends a pseudo-random percentage to the VM with the lowest balance.  Overall, the network strives to equalize balances in all VMs.

One could send Bitcoin to any of the VMs.  Withdrawals would be split among all of the VMs, distributed pseudo-randomly.

Does that make any sense?  If so, how large would N need to be?  Would this cause problems for Bitcoin overall?

I may not understand your point but this doesn't sound anonymous at all. Each transaction is logged in the block list. That makes it trivial to associate this group of nodes. By making payments from multiple nodes correlated in time you confirm the suspicion.

Somewhere I posted a simple way to have true anonymity, but it requires a trusted account that mixes coins from different people. If multiple people own the same account then no single person can be correlated with any particular payment through block list analysis.

What if there were 1,000 of them, and transfers were highly randomized in time and size?  If the system were designed properly, how would it differ from a random set of users?

This group would accept transfers from others as well.  I'd periodically pull nodes from the group to sell, and add fresh replacements.

Thanks for commenting.

I'm sure I don't understand your use case.

But if you retrying to accumulate great wealth while not being seen as a single entity, it is better if you keep your coins in addresses that don't communicate with each other. Then pay with the account with the balance that is closest to what you want to spend.

My goal is to demonstrate that one can provide ready-to-use Bitcoin-client VMs containing apparently-uncorrelated Bitcoins.  That is, I want to provide Bitcoins that apparently don't come from one entity, and can't be reliably traced back to me, or to any of my sources.  Sources would include generation, payments from customers, and anonymous cash purchases.  All IPs would be at least two-hop anonymized, and all communications would be securely encrypted.  Eventually, most of these VMs would live in the cloud.

I see what you are going for but it is going to be hard to implement. This is because of the graph nature of bitcoin transactions.

Let's start with the premise that you are trying to make this a business. And you are selling these to people who want to do something but don't want to be traced. Often that means they don't want "to get caught", which is the most important threat to you personally I presume.

So you are going to have to assume that one or more of your customers "gets caught" and see how that effects your anonymity.

Say you are selling VM's that contain 50 BTC. Assuming the client VM's are just bitcoin installations + some wallet entries (address=public/private keys) that total 50 BTC. Now if you were to sell something like this. If I bought it, the first thing I would do is think, "Hey, that guy has copies of my private keys. So they are not private at all!" So to be sure my coins didn't disappear, the first thing I'd have to do is send these coins to myself, at a completely new address so you wouldn't have the keys. If the coins weren't correlated before then, they are now.

Now assuming someone gets caught, and they say I bought this VM on the internet from an anonymous seller.

The authorities can now look back at the transaction log. They can see all the keys you included in the VM and any new keys the "caught guy" created. It is trivial to determine the creation timing of each since its stored in the block list. So the authorities can deduce, every out-point that was part of his initial VM. The associated in-points must have belonged to the VM seller (you). So they have the set of your addresses you used to create the VM. They can easily trace to see were other coins from those addresses went. They are almost sure to be VMs as well. If they see a merge structure there, that confirms a VM and gives them more of your addresses.

The more you pass coins around between your accounts, the more addresses they can correlate. The mixing patterns you describe are likely to be very obvious compared to normal transfer patterns in the transaction graph. If you mix coins that will go into VMs with coins that you spend personally, you have even more risk.

The best way for you to avoid having your accounts correlated is to buy coins in the 50 BTC quantities you will sell, and never touch the coins yourself. Just create new addresses for each 50 BTC block and have the seller's transfer the coins there directly. Then you just put each key in a VMs and sell it.

That connects your source and your customer together, but that only potentially gives away other coin addresses from the same seller.

Notice no matter what you do, if one of your customer's get caught the authorities can deduce some account that is your, and the ownership history of every coin. Your anonymity depends on who you sell to, who you buy from and your ability to remain anonymous from both of them.

Thank you for the clear response, Red.  BTW, I'm not contemplating this as a business, just for freedom and fun.

I'm obviously having a hard time fully accepting the implications of public transaction history.  As an analogy, if I impounded 1,000 $20 bills from a suspect, and each contained DNA of the same 100 people, I would suspect that they're all part of the crime.  You wouldn't see that in random samples of $20 bills.  And it's even worse for Bitcoin.

I can imagine modeling normal transaction patterns.  However, maintaining anonymity with such a scheme would require perfect implementation.  Not a good plan.

I now understand why you proposed a "trusted account that mixes coins from different people" because "no single person can be correlated with any particular payment through block list analysis".  However, I wouldn't call that anonymity, just plausible deniability -- plus guilt by association.

So, what are we privacy lovers left with?  Bitcoin-based currencies?  I don't think that'd work either, unless the identity of the basis Bitcoin were secret.   [to be continued perhaps]

Yes, you understand the issues I have with the block list now. :-)

For most people it will be "enough privacy" to just use bitcoin as designed. But if you want to say provocative things and remain anonymous while being hunted that makes things much harder.


The trusted account requires lots of users using it regularly for it to have any effect at all. That makes it akin to a bank and checking account. But an automated one that doesn't log checks. I really need to find that link. If six people use the bank they are all suspect. If six thousand use the bank, it provides some obscurity.

But I'd really like to see an implementation with the transactions totally removed from the list. There are a couple of ideas pointing to the plausibility of this. There is a thread called "not a suggestion" that discusses them.

I recall the post in question.  You proposed the account as a Tor hidden service, right?  Perhaps there's a way to implement that as a hidden grid-computing entity, with Freenet overtones.  It would be a standard option for using Bitcoin -- you'd run both a Bitcoin client and a node in the hidden-grid buffer account.  So, everyone would deposit into and spend from the same account, frustrating analysis of transactional history.

So, how would we prevent users from spending more than they had deposited?  Could the system issue Chaum ecash based on deposits, and authorize payments based on same?  That amounts to creating a security based on Bitcoin.  As with GLD and physical gold, both could be traded.

I'll look at that.  Thanks.

I have already written such a system (Open Transactions: http://github.com/FellowTraveler/Open-Transactions/wiki). As discussed in another thread on this board, my software could be run as a Tor hidden service, and it already allows you to issue Chaum-style ecash backed in whatever reserves you want (including Bitcoin). Bitcoin would be ideal as a form of reserves since it is distributed, counterfeit-proof, and publicly audit-able. Then separate software (such as mine) can add the blinding / untraceable layer as a Tor service. My software also makes it trivial to write cheques, send account transfers, withdraw in ecash, trade with any other currency types that are issued, etc.

-Fellow Traveler

Thanks, fellowtraveler.  I'd forgotten about Open Transactions.  I now recall intending to check it out.  I will.

I've launched a sender / recipient decorrelation (anonymization?) service called bitlaundry: you can get access to it at https://bitlaundry.appspot.com/ or read more about it here at: http://bitcointalk.org/index.php?topic=963.0.

I appreciate all feedback and ideas!

Is a new address generated when a direct connection is attempted or is one of the already existing addresses used?

Red, in answer to some of your comments above, now that I've launched -- I agree that more people using such a thing makes it 'normal' and therefore not notable.

However, what I have been considering is whether or not just one person sending transactions through the system would provide similar benefits in this case. My current thinking is that, if someone wanted, they could trace back the block chain and see that most of the BTC came from the same set of blocks; in essence, "no", your final anonymity is only as good as your diversity of bitcoin sources.

Thoughts?

That was my conclusion too. Because everything is public record, your anonymity is based upon how much someone cares to breach your veil. If you are the only one, it is simply a matter of drawing the lines to connect everything. You need lots of people to make the system normal. You also needs lots of regular payments to avoid correlation.

If one person puts in 33 BTC and someone else puts in 26 BTC. It doesn't matter how much you mix things in the middle, if out pops 26 BTC and then 33 BTC going to other people. Just draw the lines and mark which were mixing accounts in case they get reused.

The most anonymous situation would be to generate the coins using a node running over TOR. Then hold those coins in their separate address spending all 50 at once. Once you go mixing coins with others, you only add more possible entry points for someone to compromise.
Not sure this had anything to do with what you were asking. Sorry for the tangent.

Hi Red,

Well, the way the system works right now is that if you pump in 26, and send to say 10 recipients, they'd all get 2.5 or so; the system could easily randomize the amounts being sent -- that was on my post-launch list to do, and I'm reminded to implement that.

I also think that I will likely try and send these through mt.gox on their way out -- at that point, we'd be seeing some significant volume for other purposes.