TL:DR of Asset Name discussion

For those that missed the discussion regarding the protocol implementation of Asset names / associated prices.

I believe the forum discussion consensus that what is now considered the asset name or ‘short name’ can be used as an unique asset identifier number - where as on the GUI level asset name, description etc, can be established by convention.
i.e. (asset text field)
~~ Asset Name ~~
~~ Asset Description
PGP Link ~~

I don’t understand what this means.

Note that counterwallet allows for enhanced asset info (today, it works). See https://wiki.counterparty.co/w/Enhanced_Asset_Info_in_Counterwallet for more info.


I can add some additional fields for PGP link, etc. Any input on what is currently implemented and how it could be improved is welcome.

[quote author=xnova link=topic=279.msg2015#msg2015 date=1398021298]
Note that counterwallet allows for enhanced asset info (today, it works). See https://wiki.counterparty.co/w/Enhanced_Asset_Info_in_Counterwallet for more info.


I can add some additional fields for PGP link, etc. Any input on what is currently implemented and how it could be improved is welcome.
[/quote]

A field for a PGP link would be excellent. That, IMO, is a very good way to settle asset name ownership at the UI level.

It may be superfluous, but I think it would be good to be able to search for assets by the address, as well. If I know that a certain address has a history of issuing quality assets, it will simplify the user-experience if I can look at all the assets issued by a single address.

[quote author=cityglut link=topic=279.msg2017#msg2017 date=1398022127]
[quote author=xnova link=topic=279.msg2015#msg2015 date=1398021298]
Note that counterwallet allows for enhanced asset info (today, it works). See https://wiki.counterparty.co/w/Enhanced_Asset_Info_in_Counterwallet for more info.


I can add some additional fields for PGP link, etc. Any input on what is currently implemented and how it could be improved is welcome.
[/quote]

A field for a PGP link would be excellent. That, IMO, is a very good way to settle asset name ownership at the UI level.

It may be superfluous, but I think it would be good to be able to search for assets by the address, as well. If I know that a certain address has a history of issuing quality assets, it will simplify the user-experience if I can look at all the assets issued by a single address.
[/quote]


Added an issue for adding the PGP data support: https://github.com/xnova/counterwallet/issues/85


As far as seeing assets for a specific address, the easiest way to do that is just add that address to the wallet as a watch address. The assets owned by it will then all be visible.

[quote author=xnova link=topic=279.msg2019#msg2019 date=1398022400]
[quote author=cityglut link=topic=279.msg2017#msg2017 date=1398022127]
[quote author=xnova link=topic=279.msg2015#msg2015 date=1398021298]
Note that counterwallet allows for enhanced asset info (today, it works). See https://wiki.counterparty.co/w/Enhanced_Asset_Info_in_Counterwallet for more info.


I can add some additional fields for PGP link, etc. Any input on what is currently implemented and how it could be improved is welcome.
[/quote]

A field for a PGP link would be excellent. That, IMO, is a very good way to settle asset name ownership at the UI level.

It may be superfluous, but I think it would be good to be able to search for assets by the address, as well. If I know that a certain address has a history of issuing quality assets, it will simplify the user-experience if I can look at all the assets issued by a single address.
[/quote]


Added an issue for adding the PGP data support: https://github.com/xnova/counterwallet/issues/85


As far as seeing assets for a specific address, the easiest way to do that is just add that address to the wallet as a watch address. The assets owned by it will then all be visible.
[/quote]

An excellent point! You are absolutely right.

[quote author=AdamBLevine link=topic=279.msg2014#msg2014 date=1398004923]
I don’t understand what this means.
[/quote]

Suppose Rockxie wants to issue a GHS asset for Rockminer. Here is what it might look like:
He randomly generates or handpicks an asset name: say - ffzdJeVT
Then for the issuance the fields might look like:
Assset Name: ffzdJeVT
Text:
~~ GHS
1 GHS mining issued by Rockminer
www.example.com/assets ~~

And on the GUI level in Counterwallet this could be represented like this:
Asset: GHS
Unique Identifier: ffzdJeVT
Description: 1 GHS mining issued by Rockminer
PGP Link: www.example.com/assets

The fields don’t need to be defined by ~~ per say, , , or any other sequence that is unlikely to ever occur in text naturally would work fine. The important thing is an agreement between Asset issuers and Wallet developers (Xnova, JahPowerBit) over how Asset Information Fields are to be defined.

Forgive me if this is a stupid question. I’m not a developer.


Does the asset identifier info that you are talking about render the asset name squatting issue moot? I am thinking of the big dust-up over the ROCKMINER name that has been taking place on the BTT thread: https://bitcointalk.org/index.php?topic=395761.msg6295602#msg6295602

[quote author=sparta_cuss link=topic=279.msg2026#msg2026 date=1398057420]
Forgive me if this is a stupid question. I’m not a developer.


Does the asset identifier info that you are talking about render the asset name squatting issue moot? I am thinking of the big dust-up over the ROCKMINER name that has been taking place on the BTT thread: https://bitcointalk.org/index.php?topic=395761.msg6295602#msg6295602
[/quote]

Yes, it renders name squatting moot. Asset name-mapping can be determined at the client level in any number of ways, without changing the protocol.

[quote author=cityglut link=topic=279.msg2027#msg2027 date=1398085050]
[quote author=sparta_cuss link=topic=279.msg2026#msg2026 date=1398057420]
Forgive me if this is a stupid question. I’m not a developer.


Does the asset identifier info that you are talking about render the asset name squatting issue moot? I am thinking of the big dust-up over the ROCKMINER name that has been taking place on the BTT thread: https://bitcointalk.org/index.php?topic=395761.msg6295602#msg6295602
[/quote]

Yes, it renders name squatting moot. Asset name-mapping can be determined at the client level in any number of ways, without changing the protocol.
[/quote]

+1

A feature that myself and I think a few others would like to see is domain style asset names. This can be accommodated by introducing further conventions into the asset description.

Expanding on Porqupine’s example for ROCKMINER:

Assset Name: ffzdJeVT
Text:
~~ GHS.CLASSA
1 GHS mining issued by Rockminer
http://www.example.com/assets]www.example.com/assets~~

Assset Name: ffzdJeVwText
Text:
~~ GHS.NONVOTING
1 GHS mining issued by Rockminer
http://www.example.com/assets]www.example.com/assets~~

This would represent 2 types of GHS shares : class A with full voting rights and non voting right shares.

As long as we introduce sufficiently published rules on how to structure the description, the description could be parsed and displayed in a tree view. Asset descriptions which do not fall within spec are not displayed on the GUI and a small tool could be created to ensure asset descriptions are well formed.

|
|-GHS
|    |—CLASSA
|    |—NONVOTING
|
|-GIGAHASH
|
|-LTBCOIN

A means to disrupt people from forming an asset description which would by inserted in a different asset issuer’s tree would be to only allow assets to collapse into a node if the issuing address was all of the same.

What are the reasons for disallowing Asset Names to begin with "A"?

[quote author=Adeally link=topic=279.msg2042#msg2042 date=1398178511]
What are the reasons for disallowing Asset Names to begin with "A"?
[/quote]

This limitation is a result of the way we compress data, so as to store it in the blockchain most effectively.

[quote author=Global_trade_repo link=topic=279.msg2039#msg2039 date=1398167760]
A feature that myself and I think a few others would like to see is domain style asset names. This can be accommodated by introducing further conventions into the asset description.

Expanding on Porqupine’s example for ROCKMINER:

Assset Name: ffzdJeVT
Text:
~~ GHS.CLASSA
1 GHS mining issued by Rockminer
http://www.example.com/assets]www.example.com/assets~~

Assset Name: ffzdJeVwText
Text:
~~ GHS.NONVOTING
1 GHS mining issued by Rockminer
http://www.example.com/assets]www.example.com/assets~~

This would represent 2 types of GHS shares : class A with full voting rights and non voting right shares.

As long as we introduce sufficiently published rules on how to structure the description, the description could be parsed and displayed in a tree view. Asset descriptions which do not fall within spec are not displayed on the GUI and a small tool could be created to ensure asset descriptions are well formed.

|
|-GHS
|    |—CLASSA
|    |—NONVOTING
|
|-GIGAHASH
|
|-LTBCOIN

A means to disrupt people from forming an asset description which would by inserted in a different asset issuer’s tree would be to only allow assets to collapse into a node if the issuing address was all of the same.
[/quote]


This is very logical to me. If this, or something similar, is implemented would it affect legacy assets created with just letters B-Z?

[quote author=Adeally link=topic=279.msg2046#msg2046 date=1398182344]
[quote author=Global_trade_repo link=topic=279.msg2039#msg2039 date=1398167760]
A feature that myself and I think a few others would like to see is domain style asset names. This can be accommodated by introducing further conventions into the asset description.

Expanding on Porqupine’s example for ROCKMINER:

Assset Name: ffzdJeVT
Text:
~~ GHS.CLASSA
1 GHS mining issued by Rockminer
http://www.example.com/assets]www.example.com/assets~~

Assset Name: ffzdJeVwText
Text:
~~ GHS.NONVOTING
1 GHS mining issued by Rockminer
http://www.example.com/assets]www.example.com/assets~~

This would represent 2 types of GHS shares : class A with full voting rights and non voting right shares.

As long as we introduce sufficiently published rules on how to structure the description, the description could be parsed and displayed in a tree view. Asset descriptions which do not fall within spec are not displayed on the GUI and a small tool could be created to ensure asset descriptions are well formed.

|
|-GHS
|    |—CLASSA
|    |—NONVOTING
|
|-GIGAHASH
|
|-LTBCOIN

A means to disrupt people from forming an asset description which would by inserted in a different asset issuer’s tree would be to only allow assets to collapse into a node if the issuing address was all of the same.
[/quote]


This is very logical to me. If this, or something similar, is implemented would it affect legacy assets created with just letters B-Z?
[/quote]


We could be flexible. There could be an option on the GUI to filter out all assets which don’t have a well formed asset description. If this option was checked off, then assets which don’t confirm will end up just being top level assets.

php link capability added in https://github.com/xnova/counterwallet/commit/a80ec928e80cd9274f215f66b36e75703177eca7


will be live in production in the next few days