Anonymity and Traceability Review

[ichi]

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.

[1714152578]

1714152578

[1714152578]

1714152578

[1714152578]

1714152578

[1714152578]

1714152578

[Red]

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.

[ichi]

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.

[Red]

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.

[ichi]

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]

[Red]

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.

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]

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.

[ichi]

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.
I always strive to plan for the worst-possible scenario.  "I was being conservative" is always a better deposition answer than "it didn't matter" 

Anyway, I'm not comfortable with "enough privacy" -- even for people who don't think they're concerned.  Circumstances change, and people end up in trouble in mays they never suspected.  IMHO, most people assume that they're fundamentally anonymous online unless they explicitly reveal information, and blithely accept assurances of stronger anonymity from service providers.  And then their "anonymous" blog gets hosed by a court order, or whatever.

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]

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.

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.

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'll look at that.  Thanks.

[fellowtraveler]

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

[ichi]

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

[vess]

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!

[mizerydearia]

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.

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

[vess]

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?

[Red]

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.

[vess]

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.