Topic: Anonymity and Traceability Review (Read 19787 times)

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.

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.

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?

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

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: https://bitcointalksearch.org/topic/announcing-bitlaundry-decorrelated-payment-service-963.

I appreciate all feedback and ideas!

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

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

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.

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.

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]

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.

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'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.

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 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.

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?

"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 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?

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.

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.