Idea: namespace for "colored zerocoins"
Posted: Fri Sep 19, 2014 2:06 am
Okay, so this is an idea that hasn't gotten much thought. So there may be problems. But, I figure it might be cool, and I can see one application of the idea that would really help me in some CS research I'm doing. So, I'm putting it out there in the hopes that someone can either tell me how it's broken, or tell me how to make it less broken. (Or maybe it's not broken at all... that would be cool.)
I'm assuming that you've read the Zerocash paper. If not, go read that first.
Zerocash uses a single merkle tree to store all zerocoin transactions. This makes all zerocoins indistinguishable from each other. This is desirable for currency applications, since we want currencies to be fungible.
But what if we want the anonymous equivalent of colored coins? Specifically, what if we want N colored coins to be issued, and be indistinguishable from each other, but still identifiable as from that set of N colored coins? What if we want those colored coins to be divisible and mergable, while retaining their color?
I propose a Namecoin namespace "zc/" (abbreviation for ZeroColor). Here's how it works:
A user, whom we'll call the "issuer", creates a name in the zc/ namespace, which creates a new set of colored zerocoins (which we'll call the "currency"). The name contains enough information to initialize the merkle tree with the individual zerocoins. The output permissions of the name is set to "unspendable", meaning that a currency expires 36000 blocks after being issued. (Making them renewable is possible but makes it more complicated.) We'll call the name "zc/currency1"
Another user, whom we'll call the "spender", then creates a Zerocash pour transaction (sending to a user whom we'll call the "redeemer"), using the merkle tree of zc/currency1, and creates a new name using zc/currency1 as a second-level namespace. We'll call this name "zc/currency1/pour1". The Zerocash pour transaction is placed in this name.
From this, the redeemer has the ability to prove that he/she possesses a zerocoin belonging to the currency. However, the redeemer is completely anonymous to the issuer (as well as blockchain analyzers), assuming that the name itself is not traceable to the redeemer (so Zerocash support in Namecoin is a prerequisite, as is accessing the Namecoin network via Tor).
This potentially has use cases in web of trust applications (because you can prove that there is a trust chain between two users, without leaking the users' social graph). I haven't thought about it carefully, but it might also be useful for liquid democracy applications. I personally want to use this in an anti-spam algorithm that preserves anonymity and isn't vulnerable to attackers with large PoW-solving resources.
Other notes: if you're using this for web of trust, you can send smaller-denomination zerocoins to entities that you trust less. If they receive trust from multiple people, they can merge those coins in a pour transaction. Since this is Namecoin, you can also attach arbitrary data to a zc/ transaction, which might have interesting applications (e.g. for liquid democracy votes, or for delegating trust from one colored zerocoin currency to another).
So, is this idea workable or totally broken? Thoughts on how to make it better?
EDIT: Regarding the data in the issuing name, I think it would be sufficient to make the issuing name contain an array of Zerocash mint transactions. This would explicitly make the supply of the currency public knowledge (and could be manually audited against the amount of NMC locked in the name if desired; see my reply to Mike below). Mint transactions are only allowed in the issuing name; subsequent names can only contain pour transactions (so inflation is not possible).
I'm assuming that you've read the Zerocash paper. If not, go read that first.
Zerocash uses a single merkle tree to store all zerocoin transactions. This makes all zerocoins indistinguishable from each other. This is desirable for currency applications, since we want currencies to be fungible.
But what if we want the anonymous equivalent of colored coins? Specifically, what if we want N colored coins to be issued, and be indistinguishable from each other, but still identifiable as from that set of N colored coins? What if we want those colored coins to be divisible and mergable, while retaining their color?
I propose a Namecoin namespace "zc/" (abbreviation for ZeroColor). Here's how it works:
A user, whom we'll call the "issuer", creates a name in the zc/ namespace, which creates a new set of colored zerocoins (which we'll call the "currency"). The name contains enough information to initialize the merkle tree with the individual zerocoins. The output permissions of the name is set to "unspendable", meaning that a currency expires 36000 blocks after being issued. (Making them renewable is possible but makes it more complicated.) We'll call the name "zc/currency1"
Another user, whom we'll call the "spender", then creates a Zerocash pour transaction (sending to a user whom we'll call the "redeemer"), using the merkle tree of zc/currency1, and creates a new name using zc/currency1 as a second-level namespace. We'll call this name "zc/currency1/pour1". The Zerocash pour transaction is placed in this name.
From this, the redeemer has the ability to prove that he/she possesses a zerocoin belonging to the currency. However, the redeemer is completely anonymous to the issuer (as well as blockchain analyzers), assuming that the name itself is not traceable to the redeemer (so Zerocash support in Namecoin is a prerequisite, as is accessing the Namecoin network via Tor).
This potentially has use cases in web of trust applications (because you can prove that there is a trust chain between two users, without leaking the users' social graph). I haven't thought about it carefully, but it might also be useful for liquid democracy applications. I personally want to use this in an anti-spam algorithm that preserves anonymity and isn't vulnerable to attackers with large PoW-solving resources.
Other notes: if you're using this for web of trust, you can send smaller-denomination zerocoins to entities that you trust less. If they receive trust from multiple people, they can merge those coins in a pour transaction. Since this is Namecoin, you can also attach arbitrary data to a zc/ transaction, which might have interesting applications (e.g. for liquid democracy votes, or for delegating trust from one colored zerocoin currency to another).
So, is this idea workable or totally broken? Thoughts on how to make it better?
EDIT: Regarding the data in the issuing name, I think it would be sufficient to make the issuing name contain an array of Zerocash mint transactions. This would explicitly make the supply of the currency public knowledge (and could be manually audited against the amount of NMC locked in the name if desired; see my reply to Mike below). Mint transactions are only allowed in the issuing name; subsequent names can only contain pour transactions (so inflation is not possible).