These seem to be all the buzz lately. Ever since coinvalidation was announced at the end of last year, it ignited a spark within the community to work on furthering anonymity within the bitcoin protocol. 3 months later, we have a few working samples. Do they actually solve the problem though? First, it might help to define what the problem is.
First off, there’s the issue of maintaining fungibility. Imagine going to the store and being told you can’t spend your money because at some point in the past, it was used in a drug deal. That’s exactly what the goal of coinvalidation is. Governments and other entities would be all over this sort of thing if it ever came to fruition, so it’s a very real threat. Since a currency can not functionally exist without fungibility, coinvalidation seeks to essentially destroy bitcoin in order to make a quick buck. To counter this threat, their data must be poisoned. This involves conducting transactions in such a way that sources and destinations of coins are muddied.
Second, is the problem of user anonymity. As I’m sure you all know, bitcoin is only pseudonymous at it’s core. Since all transaction data is public knowledge, the only thing preventing someone from having access to your full financial history is them not having a full list of addresses you control. Compiling such a list is easier than it may seem, though. For example, if an entity controlled hundreds of nodes on the network, and maintained an active connection to every other node, they would be able to determine the originating IP of every single transaction on the network. From here, it’s not too difficult to associate groups of addresses with one another, and even associate addresses with a specific person. This is not a hypothetical scenario, as I assure you that there are companies and other entities gathering this sort of information right now. There are a few other methods that can be used to gather this type of information, but that’s not the focus of this article so I won’t go into it any further.
Now, onward to the point of the article. I’ll briefly go over each implementation and it’s advantages/disadvantages. The ultimate test, though, will be whether or not it could reasonably be implemented on the bitcoin network. If the answer to that is no, then it fails. Solving the problem of anonymity is only half of the solution – scalability is just as important.
Darkcoin
Darkcoin has a feature called “darksend” which is really just a cutesy name for it’s implementation of gmaxwell’s coinjoin specification. Essentially, inputs from multiple entities are grouped together and treated as one transaction. To an outside observer, this makes it more difficult to tell exactly what addresses belong to who.
The nice thing about this implementation is that it doesn’t require much additional overhead, and doesn’t require trusting third parties, meaning it could reasonably be implemented into bitcoin. At the same time, the level of anonymity it affords is only moderate at best. It is best used in conjunction with other methods of anonymity. On it’s own, it likely isn’t enough. AFAIK, darksend isn’t publicly released yet either.
Zerocoin (unreleased)
Zerocoin is the most complex of the bunch. It uses a combination of digital commitments, one-way accumulators, zero-knowledge proofs, and some extensions to the existing bitcoin protocol to attain an extremely high level of anonymity. It’s difficult to translate all of this into simpler terms, but if you’re interesting in a more ‘technical’ explanation you can find it here.
Of course, such a high level of anonymity does not come without tradeoffs – zerocoin has a high amount of overhead. A zerocoin proof (344 bytes) is needed for each transaction, and stored within the blockchain for eternity. These proofs must be processed by network nodes, adding not only significant storage bloat, but computational requirements as well. Keep in mind that the average bitcoin transaction is about 400 bytes in size, so this is no small amount.
Zerocoin is not even released yet, so it could very well trim itself down before then. For reference, the first implementation used a 50kb proof… But in it’s current state, it doesn’t scale very well. It would function just fine as an altcoin, but if you were to scale the network up to bitcoin size, it’s likely too bloated for it to work. Also worth mentioning is that all the fancy math that zerocoin employs could also open the door for some sort of unforeseen exploit.
TiPS
TiPS is the simplest of the bunch. Nothing too exotic here, they’ve just taken a coin mixing service and run some parts of it on top of the blockchain. Functionally, it doesn’t differ a whole lot from sites like bitcoinfog. Mixing involves sending your coins to an intermediary that controls a big “pool” of coins. Then, different coins, not the ones you sent, are what ultimately reaches the intended address. This provides a fairly simplistic, but effective, means of masking source and destination.
This method doesn’t incur a lot of overhead, and provides a high degree of anonymity if done properly. It is also easy to employ mixing with other methods as it’s not a protocol level activity. However, this entails putting a lot of trust into the operator of the mixer – not only that he won’t run off with your coins, but also that he won’t keep logs that would compromise your anonymity.
Anoncoin
Anoncoin gets an honorable mention for having the ability to route traffic over TOR/I2P. This does a pretty good job at preventing people from associating transactions with IP addresses, but doesn’t do much else. It’s not a great deal different than the proxy functionality already built into bitcoin based clients.
Conclusion
None of these solve the problem completely. Currently, darkcoin with it’s coinjoin implementation is likely the most reasonable proposal. It is, however, a incomprehensive solution, so take that with a grain of salt. Zerocoin has the greatest amount of potential going forward.
Discuss this article over at the CryptoLife forum.
What about the innovation with stealth addresses? I know they haven’t been implemented (as far as I know) but don’t they reasonably solve the problem?
“We’re now at 240 bytes.” – Matthew Green, Nov 17, 2013. Did they go backwards or is the # in your article incorrect? I would think by now the # would be even lower than the # given in Nov ’13.
huge +1 for using the word “cutesy”.
also I actually got a lot from this – i’d tip if you had a QRK address showing : )
when you speak on a subject you do it with an air of respectability
Hi,
How about solving the anonymity problem by having half the coins pre-mined and when sending to an address send coins through that wallet.
send amount from X -> Y would be in fact an order for X -> pre-mined; pre-mined -> Y
The pre-mined wallet will always contain half the coins that will ever be, so it’s easy to check if the owner of the coin is spending more than he should….
or some other way of making this wallet unspendable all by itself (without getting coins from wallet X.
that would mean each block would contain 2 transactions, one to Y, and one from Y
interesting concept, kind of a more extreme coinjoin
but the problem is that if anyone manages to crack the premine adress all other users of the currency get goxed
That’s why it should be hardcoded that the first wallet only works as a transfer mechanism.
– it can’t spend if it didn’t receive a payment first
– can never have a balance lower then MAXCOINS/2
And another precaution would be to break payments into random tiny installments.
Ex.: I send you 2 BTC (make it like a masspayment, with multiple addresses, but in the ledger only record 2BTC to main wallet, so we know that money is spent) =>
2 BTC -> first wallet -> rand(0,2) BTC -> addressA, rand(0,first rand) – >addressB, ….. if amount is less then X, send all of it to addressZ
I think this could actually work. I’m courious to see what Hazard thinks of this solution.