Existing reddit thread:
http://www.reddit.com/r/counterparty_xcp/comments/2bgnwb/dogeparty/
Cross-posting here…
The issue:
Assume that sooner than later their will be dozens of AltParties launched like DogeParty. This opens a can of worms in the context of asset name clashings. IP, branding, scams, phishing, general confusion etc all become a burden for asset issuers and potential token holders. Now that DogeParty is launching the first significant alternate CounterParty platform, this is the time to discuss the issue and attempt to come to some consensus as to whether or not to be proactive or let chaos sort itself out.
Some Possible Solutions:
1) One thought I had earlier on when I dealt with an altcoin name clash issue was to setup a registrar akin to domain names but do it using Blockchain technology. I talked to Ryan Shea at onename.io about firing up another instance at onecoin.io so altcoins (and now metalayer assets/tokens) can be claimed/registered and have this be a condition for exchanges to reference prior to listing a new coin/asset for public trading. This type of service could be integrated into CounterParty and new AltParties so that when creating new assets, it checks for existing asset names and adds new asset names accordingly based on availability. This would be a preferred feature to enable but not truly enforceable across all AltParties.
However, this type of token registry system could be supported by the community and help guide new users looking to buy an asset by showing an extra layer of validity (verified badge etc) that wallets and exchanges could leverage to show which assets and issuers are more trustworthy and legitimate in the market verse more rogue AltParties that choose to allow for the duplication of asset names and thus contributing to the aforementioned issue at hand.
It would essentially be a system levergaing both zero trust technology (blockchains such as namecoin and similar) as well as trust based human participation (those running altcoins and altparties). Theoretically, ALL crypto-asset related platforms could also adopt this type of service if they believe it will have benefits within this ecosystem. It also can create a second market whereby assets and altcoins can be bought and sold just like the domain industry.
2) No Blockchain use, rather extend CounterParty to support a federated asset meta data feed that continuously self-verifies and consists of all unique asset names created across all AltParties and CounterParty itself. An asset cannot be created unless that asset name has not been used on any AltParty. In this P2P based distributed data feed (JSON) will exist all meta data about the asset. It would be expected that eventually further enhancements are made to CounterParty protocol and code to support interoperability and cross-party asset transactions so an asset created on one AltParty can either be moved to another “SideParty” entirely or recognizable and able to transact tokens across AltParties. See Jeremy’s thoughts on using Vennd to facilitate this via Proof of Burn and shared private key of deterministic counterwallets. This would be simpler to run on the backend since blockchains are not used.
3) A new Claim system inside CounterWallet for claiming assets. This may also rely on Vennd. This could work by initiating a claim on behalf of an original asset issuer as soon as another asset issuer on another AltParty tries to create an asset with the same name. Essentially, the asset does not get created after a verification of name availability fails and instead a claim token is sent to the original asset issuer (vennd handles) and this can be used to successfully create the asset on the AltParty by the orignal asset name issuer. The claim token needs to be a smart token otherwise a new asset would need to be dynamically created for this purpose. For example, LTBCOINCLAIM with 1 token issued is created and the 1 token is sent to the original issuer of LTBCOIN on the other AltParty (or CounterParty). The original asset name creator would be able to use this LTBCOINCLAIM token to successfully claim and create the LTBCOIN on the AltParty. Vennd could be useful here unless it could somehow be natively supported within the CounterParty protocol and codebase.
4) CounterParty is obviously the first platform to launch (counterparty.co) and this could possibly be leveraged by making CounterParty’s database of asset names BE the registrar whereby all other AltParties use for checking asset name availability. This is interesting because it actually could provide support for both CounterParty and Bitcoin since every asset name needs to first be created there (requiring XCP and maintaining utility value of Bitcoin/Blockchain). Since every AltParty is re-using the CounterParty code and protocol for their own projects… this is a nice way to support CounterParty by letting it be the Asset Registrar. Again, this would be optional as mentioned earlier but it would provide that layer of legitimacy that can be important in the ecosystem.
5) Forgo prevention of name clashing and focus on authenticity (SSL certificate associations), reputation systems and other data factors.
6) Your Own Ideas or Variations of those I have provided.
Also worth referencing:
Asset Issuance Standard
https://github.com/gidgreen/spec/blob/asset-issuance/AssetIssuanceStandard.md
Enhanced Token Info in Counterwallet
https://wiki.counterparty.co/w/Enhanced_Token_Info_in_Counterwallet
I’m for #4, but it’s a “sensitive” issue because there’s a fair number of lurkers already and when names already clash (see Namecoin), it may not work well…
A new type of asset (nameasset?) sounds interesting until one considers existing asset owners who registered their names thinking that was enough…
Disclosure: I haven’t issued any assets on Counterparty yet and don’t have plans to do so in the near future.
What’s interesting with most of these options is that it would be OPT-IN by those in charge of each counterparty platform. So the community and ecosystem are able to use this info on the UI layer which could enable users in the open markets to make better decisions (from their perception and interpretation of the data). It could be feasible that over time, users will have tendencies to buy and use asset tokens from platforms that opt-in to using anti-clashing asset name systems rather than rogue platforms that do not enable these features. Either way, the market decides. But to even get to that point, the technology needs to allow for this functionality to exist. Otherwise, we leave it up to chaos and hope for the best. Since technology + motivation can add powerful functionality to any system, I think it is worthy of not only discussion, but eventual development.
[quote author=sull link=topic=464.msg2913#msg2913 date=1406262091]
What’s interesting with most of these options is that it would be OPT-IN by those in charge of each counterparty platform. So the community and ecosystem are able to use this info on the UI layer which could enable users in the open markets to make better decisions (from their perception and interpretation of the data). It could be feasible that over time, users will have tendencies to buy and use asset tokens from platforms that opt-in to using anti-clashing asset name systems rather than rogue platforms that do not enable these features. Either way, the market decides. But to even get to that point, the technology needs to allow for this functionality to exist. Otherwise, we leave it up to chaos and hope for the best. Since technology + motivation can add powerful functionality to any system, I think it is worthy of not only discussion, but eventual development.
[/quote]
#1 doesn’t sound bad either. I think it’s reasonable to use the Bitcoin blockchain for obvoius reasons.
I wonder whether it’d be better to come up (or build a new project) with a plan to address several issues at once - asset names, domain names, personal identities (“open bit ID”?), etc. Otherwise as things develop we’ll need more and more separate packages to get all these requirements covered (and assets and domain names are basic requirements).
Here is what Flavien Charlon emailed me about their approach with coinprism:
“The way it works is that the color metadata file is hosted on the servers of the issuer, using SSL (say https://www.amazon.com/asset-definition). Coinprism simply examines the SSL certificate, which in that case points to the organization “Amazon.com Inc” (see: http://www.sslshopper.com/ssl-checker.html#hostname=www.amazon.com), and this has been verified by CAs such as Verisign. So we use that to tell the user: this coin has been issued by “Amazon.com Inc”. It’s optional though, so name clashes are still possible, but name clashes amongst “verified” issuers is very hard."
[quote author=sull link=topic=464.msg2921#msg2921 date=1406303292]
Here is what Flavien Charlon emailed me about their approach with coinprism:
“The way it works is that the color metadata file is hosted on the servers of the issuer, using SSL (say https://www.amazon.com/asset-definition). Coinprism simply examines the SSL certificate, which in that case points to the organization “Amazon.com Inc” (see: http://www.sslshopper.com/ssl-checker.html#hostname=www.amazon.com), and this has been verified by CAs such as Verisign. So we use that to tell the user: this coin has been issued by “Amazon.com Inc”. It’s optional though, so name clashes are still possible, but name clashes amongst “verified” issuers is very hard."
[/quote]
The process is reasonable but it has these dependencies that one has to have a non-self-signed SSL cert and a Web server (prehaps not unreasonable, but more costly).
Few months ago I wondered PGP and WoT could be used since that approach is cheaper and has been used with success (http://bitcoin-otc.com/trust.php), although I’ve found it complex from the end user standpoint (you lose your server and SSL cert, you get a new one; you lose your PGP keys, ?).
Flavien further wrote:
“What we do in Coinprism is not preventing name clashes per se, but rather help the user identify genuine issuers amongst several issuers pretending to be the same. So many different people can claim to be Amazon, but Coinprism (and the protocol we use in general) provides a mechanism for being able to tell who is the real Amazon.”
“Using Blockchain tech like namecoin would help solving the name clash problem in a decentralized way, but it wouldn’t solve the authenticity issue: being Amazon on namecoin doesn’t mean you are the Amazon. We are more concerned about solving the authenticity problem as this lets users use the trust framework they already have (“I trust Coca-cola, I trust Amazon, I don’t trust Randomcorp”).”