Idea: namespace for "colored zerocoins"

Post Reply
biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Idea: namespace for "colored zerocoins"

Post by biolizard89 »

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).
Last edited by biolizard89 on Sat Sep 20, 2014 1:52 pm, edited 1 time in total.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

John Kenney
Posts: 94
Joined: Sat Mar 29, 2014 2:20 pm
os: linux
Location: Sheffield, England
Contact:

Re: Idea: namespace for "colored zerocoins"

Post by John Kenney »

Sounds interesting, but I'm not sure I fully understand it, I'll read that Zerocash paper...

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Idea: namespace for "colored zerocoins"

Post by virtual_master »

biolizard89 wrote: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?
It is an interesting idea but almost so unrealistic at the moment like my idea to store a human brain in the blockchain. :D :D :D
Zerocoin/Zerocash is interesting but still nowhere implemented.(eventually in some closed specific testing environments)
Colored coins are also interesting but in an early stage.
Should we combine two still unreliable or not working technologies before they work and tested to work at least separated ? :D
But I am sure in one year we can have a better look on this specific proposal.

We shouldn't forget what the purpose of Namecoin is. A censorship and hacking resistant technology for domains, identities, assets and eventually data storage tracking. That require both security and privacy in some extent.
But I wouldn't prioritize anonymity higher than security, which would be the case by implementing Zerocoin/Zerocash even alone at the actual stage of development.

May be you understood this new technologies better than me.
But I would say we should go from simple to more sophisticated and we shouldn't jump over them only if we have the capacity. (the development capacity)
This require the basic and general understanding of technology. My opinion.

Something for assets like Colored Coins or side-chains or something similar with what they announced by Peercoin could be useful.

Improving privacy with more simple and better tested technologies like coincontrol and stealth addresses would be more easier then implementing Zerocoin/Zerocash. This combination would be more secure even if not so anonymous than Zerocash.
Transaction size, which is higher by Zerocoin/Zerocash or by Ring Signatures( like by Monero)is also an issue.

Implementing modular and step by step wouldn't bring all together to crash. They will be anyway combined in Namecoin if you receive coins on a stealth address and then you register a name with it representing domain, identity or asset with colored coins.

The problem with namespaces is that people don't keep on the specifications.(name squatting, name squatting avoidance or just unlogic or individualistic behavior)
And that could be eventually a bigger problem by assets than by domains or IDs.
Because of this I propose to implement the possibility of registration of a namespace (at least in some controlled circumstances like above 10 characters and for a higher fee). This could solve eventually the development problem also as external institutions/organizations could be more interested to use the Namecoin blockchain to issue their own assets. The namespace owner would be the only who could register names in his namespace. However receiving control over a name in a private namespace representing whatever asset, only the name owner could sell or send it to another private key owner. What do you think about it ?
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Idea: namespace for "colored zerocoins"

Post by biolizard89 »

Well, yes, this idea is not implementable until Zerocash is ready for deployment. That's an entirely separate debate. The use cases I'm looking at probably require Zerocash; can you figure out a way to implement this properly using stealth addresses and coin control? As for colored coins, my understanding is that the concept is implemented and working, just there aren't any noteworthy applications using it.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Idea: namespace for "colored zerocoins"

Post by virtual_master »

biolizard89 wrote:Well, yes, this idea is not implementable until Zerocash is ready for deployment. That's an entirely separate debate. The use cases I'm looking at probably require Zerocash; can you figure out a way to implement this properly using stealth addresses and coin control?
No. Unfortunately I cannot figure out how could work for the web of trust.
I thought more on anonymizing how to send coins, domain names and assets and for that would work Stealth address also. Coincontrol of course would work only for coins.
Zerocoin/Zerocash would cover probably more use cases and would also assure a higher anonymization level in every case. But I cannot confirm if would work properly in your case.

The proposed namespace is OK for me.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

mightbemike
Posts: 57
Joined: Fri Apr 25, 2014 4:40 am

Re: Idea: namespace for "colored zerocoins"

Post by mightbemike »

For what little it's worth I think it's a great idea. Building a meta-layer on top of Namecoin adds a boatload of value. Just because there's not a lot of people using colored coin implementations now doesn't mean it doesn't work. In fact I think they've been fine-tuning the implementations for some time now and it's reliable. But like John, I'm not fully understanding parts of this. Also I can't follow the math in the zerocoin paper :(

It sounds like anyone who wants to issue tokens against some asset, say shares of a company, would register a name in this new namespace and put sufficient NMC to be as divisible as they require. Your idea is to create a new merkle tree for this asset, and another for every other asset that was represented this way, right?

And you're just talking building in support for the merkle trees, it would be up to the "colored zerocoin" developers to actually build that thin layer on top to implement any features of convenience, yes? Sounds like a brilliant idea, unless I totally misunderstood it.
NMC: NFhmGAqzRpZbGs3uCPPo7DJKuscuL4Aap2
id/mightbemike

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Idea: namespace for "colored zerocoins"

Post by biolizard89 »

mightbemike wrote:For what little it's worth I think it's a great idea. Building a meta-layer on top of Namecoin adds a boatload of value. Just because there's not a lot of people using colored coin implementations now doesn't mean it doesn't work. In fact I think they've been fine-tuning the implementations for some time now and it's reliable. But like John, I'm not fully understanding parts of this. Also I can't follow the math in the zerocoin paper :(

It sounds like anyone who wants to issue tokens against some asset, say shares of a company, would register a name in this new namespace and put sufficient NMC to be as divisible as they require. Your idea is to create a new merkle tree for this asset, and another for every other asset that was represented this way, right?

And you're just talking building in support for the merkle trees, it would be up to the "colored zerocoin" developers to actually build that thin layer on top to implement any features of convenience, yes? Sounds like a brilliant idea, unless I totally misunderstood it.
Hi Mike, I'll try to clarify.

Yeah, the math in the Zerocash paper is beyond me too. (I haven't yet taken a formal crypto course, that's next semester. So while I understand the concepts described, the underlying math isn't something I understand either.) Luckily the Zerocash paper is pretty good at providing high-level explanations of the concepts in addition to the math. So, an understanding of the "plain English" in the Zerocash paper should be sufficient to follow my proposal.

The colored zerocoins aren't "backed" by NMC in the standard sense, other than being rate-limited by the name creation fees. Anyone can create a colored zerocoin currency with whatever supply they like, by creating a name. However, the Namecoin protocol allows more than the standard 0.01 NMC name fee to be allocated to a name. Since in this case the name is "unspendable", those extra NMC are permanently locked. So, if a particular application requires backing colored zerocoins with a certain amount of NMC, then that can be enforced by checking how much NMC is locked in the name. While the supply can be arbitrary, the supply must all be created in the initial name. Since only pour transactions are supported, not mint transactions, inflation is not possible.

Yes, the idea is to have user software (either NMControl or client software using NMControl; definitely not namecoind) calculate merkle trees for colored zerocoin currencies. This would probably be limited to specific colored zerocoin currencies that the user is interested in. It's not necessary to calculate that data for all currencies; the full Namecoin hashrate applies to all the currencies since this is using standard Namecoin names, so a 51% attack is not possible even though the markle tree data is not being validated by the full Namecoin network. This does mean that fraudulent markle tree spends can be accepted to the blockchain; user software will have to ignore those instead of just trusting the blockchain as is done with Bitcoin and most Namecoin namespaces.

Any practical applications (web of trust, liquid democracy, etc.) would be done by user software (downstream of the user software that calculates the merkle trees) and are not covered by this proposal.

I have a minor clarification to the proposal which I will add to the original post.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply