We are exploring the possibility of reducing the fee for user-created assets when we merge the chains. bytemaster has expressed openness to reducing the fee to 10 BTSX or even less. In this post, I would like to address the implications of such a policy.
Disclaimer: While I am now officially a member of the I3 team, this post has not yet been adopted as an official I3 policy. As of this writing, we have not yet reached internal consensus at I3 about how to handle the issues I raise in this post.
In terms of network resources, processing user-created asset transactions costs no more or less than processing transactions for built-in BitAssets. From a technical standpoint, implementing issuing, transferring, and market matching of bids/asks for user-created digital tokens already exists in the code. Reducing the fee charged for these transactions to reflect their cost to the network will encourage new applications and keep someone from forking BitShares and "eating our lunch".
The main problem is that currently user-issued assets and built-in assets live in a shared global namespace. I think the cleanest way to deal with the problem is to separate the system into two parts. (1) Internally, each asset should have a unique identifier, a hex string which is the hash of a JSON "asset descriptor" object describing the purpose of the asset, how many are issued, etc. (2) Then we should provide a mapping mechanism allowing names in a more human-friendly namespace to be mapped to asset descriptor hashes.
Under the mapping mechanism, short or memorable names in the namespace are scarce resources. A market-based mechanism is the best way to discover their value. Fortunately, in the merged chain we are already planning to implement a market mechanism allowing price discovery for allocation of names in a namespace -- that is the entire purpose of DNS / KeyID.
I propose the following mapping mechanism:
- All one-to-four character entries in the global namespace come into existence as market-based assets when a majority of delegates publish an asset descriptor indicating their support.
- Five or more character entries belong to the owner of the corresponding .coin domain and are allocated by the DNS auction process.
- Per-account entries such as drltc.titan/mytoken can be allocated to the owner of the corresponding TITAN account.
- .coin URL's such as drltc.coin/mytoken can be allocated to the owner of the corresponding .coin domain.
Each of these namespaces serves a different market. One-to-four character entries are likely the same as real-world stocks and commodities. The cost and setup time is high -- adding a token requires convincing a majority of delegates to support it.
Five-or-more character entries are usable by people who want tokens inscribed with their brand. The cost and setup time is medium -- they must obtain a DNS name, which is substantially less difficult than convincing 51 delegates, but substantially more time-consuming and expensive than a single transaction fee.
Per-account or TLD entries are most suitable for small experiments or private-issue tokens. For these applications, branding is not a concern so long as the coin has *some* human-readable, globally unique identifier. Speedy turnaround time and low cost are still desirable. The cost and setup time is small -- simply paying a transaction fee.
For simplicity of implementation, the name-to-asset-descriptor mapping should only be mutable if all tokens have been burned.
On Friday, at I3 we internally discussed an idea based on a hard-coded list of one-to-four letter names representing real-world stocks and commodities. Upon reflection, I've come to believe that such a scheme is inherently brittle, essentially requiring a hardfork if the hard-coded list is incomplete.
Topic: drltc's User Issued Asset Proposal (Read 3796 times)
