Invalidate assets created using the same name as an already issued asset

[genecyber]

I don't think the protocol should allow assets with the same name as it opens up a hole for someone to introduce confusion by making multiple assets of someone else's asset. This can be very confusing in an exchange environment.

The UI can easily handle this check and not allow the tx to be generated. The API should be able to handle it as well. In the event that someone manually creates the tx and pushes it, the core should ultimately invalidate the second asset. IMHO

[achamely]

This borders on spec discussion and may be better suited over there, especially when you start talking about invalidating tx.
Within Omni we should have the ability to do some additional checking into the name so it compares against existing tx and we can reject it before submitting. @ripper234 @marv-engine thoughts?

[marv-engine]

This topic has gotten a lot of discussion. That's why the spec says that UI's should always show the currency id in parentheses following the property name. That certainly doesn't eliminate any confusion, but it could reduce it. Also, UI's should provide quick/easy access to details about a SP.

This is a case where a UI could use context indicated by advisory attributes to filter/tailor information presented to the user to reduce confusion.

@achamely, rejection can be a difficult emotional experience. For now at least, I prefer a warning, with a list of name collisions.

[genecyber]

If I was working hard in a crowd sale for say IPOCoin and right at launch someone came in and created an asset with the same name but sold it at a crazy low price. Maybe the attacker also flooded the system with decoy assets so that the similar assets would not be next to each other on a page of recent crowd sales. The potential confusion could be devastating. 

Less so I guess if the standard workflow isn't to come to some site and search for an asset to find out how to buy, but I can see myself hearing about IPOCoin and just coming to a site and looking up the details and clicking the first one I see. 

Feel free to ignore as I understand I'm coming into this discussion way late.

On Fri, Jun 27, 2014 at 10:29 AM, Marv Schneider [email protected]
wrote:

This topic has gotten a lot of discussion. That's why the spec says that UI's should always show the currency id in parentheses following the property name. That certainly doesn't eliminate any confusion, but it could reduce it. Also, UI's should provide quick/easy access to details about a SP.
This is a case where a UI could use context indicated by advisory attributes to filter/tailor information presented to the user to reduce confusion.

@achamely, rejection can be a difficult emotional experience. For now at least, I prefer a warning, with a list of name collisions.

Reply to this email directly or view it on GitHub:
#644 (comment)

[ripper234]

@genecyber - thanks for the post. I think that the right way to solve this would be to implement a Name resolution system at the protocol level.

In the meantime, Omni should not pose artificial restrictions on the Name field (it should warn about potential duplicates though when possible and applicable - but beware not to open up a DOS vulnerability when someone spams 1000 names and a dialog with 1000 possible candidates appears to the user)