Allow Named Assets to Begin with A; Allow Longer Names

[Jpja]

This is a proposed protocol change:

• From a specified future block, interpret new registrations with ID >= 1.82e19 as named assets beginning with A.

This implies that new registrations above that threshold no longer become numeric assets.

Names will get mapped with base 27 (b27_digits = ' ABCDEFGHIJKLMNOPQRSTUVWXYZ'). If a (space) is detected, the registration is invalid. If the first character is not A, the registration is invalid.

JS functions for converting between ID and name:

 ` function asset_name_b27(id) {
    const k = BigInt(1.82e19);
    let b27_digits = ' ABCDEFGHIJKLMNOPQRSTUVWXYZ'; 
    let n = BigInt(id);
    let name = '';
    n -= k;
    do {
      let mod = n % 27n;
      name = b27_digits[mod] + name;
      n -= mod;
      n /= 27n;
    } while (n > 0);
    return name;
  }

  function asset_id_b27(name) {
    const k = BigInt(1.82e19);
    let b27_digits = ' ABCDEFGHIJKLMNOPQRSTUVWXYZ'; 
    let name_array = asset_name.split("");
    let n_bigint = BigInt(0);
    for (i = 0; i < name_array.length; i++) { 
      n_bigint *= BigInt(27);
      n_bigint += BigInt(b27_digits.indexOf(name_array[i]));
    }
    n_bigint += k;
    return n_bigint.toString();
  }`

Note that the largest A-name (assuming max 12 chars long; ZZZZZZZZZZZZ) will get ID ~ 1.84e19, slightly below the theoretical maximum. We can of course decide on a different k to have ZZZZZZZZZZZZ match the exact maximum, or to minimize collisions with existing numeric assets, etc.

Also note that the above functions are very similar to how names have been registered (and will continue to be registered). The differences are k = 0 and base 26. With b26 it just happens that names cannot begin with A.

[jdogresorg]

This is an interesting proposal. Thank you for taking the time to write it out, including all the technical details :)

Unfortunately, at this time I oppose this change as I feel it breaks the fundamental rules that were established when the name system was created.

• No names that start with A
• 4 Letters is shortest allowed asset

If users are now able to register A names, or register shorter names, I feel it essentially screws over many of the long-time counterparty users who registered X names like XAPPLE with the understanding that there would never be any asset names starting with A allowed.

While we may be able to do this from a technical perspective, I object to this change, as I feel it changes the fundamental rules of asset names, and is unfair to existing users and asset holders.

[jotapea]

• No names that start with A
• 4 Letters is shortest allowed asset

I agree @jdogresorg. This is basic asset name validation logic for Counterparty applications. 3 letter assets are the protocol ones (so, I wouldn't mind adding another 3 letter asset if it has special functionality like XCP does). And A assets serve as clear indication these are either numeric or longnames.

Relevant related discussion: https://github.com/CounterpartyXCP/cips/discussions/87.

[DerpHerpenstein]

I think that there is alot of value in expanding the asset names. Adding A helps, but doesn't really solve the issue that the 4-12 latin character namespace is a severe hindrance on global adoption.

Another way to do this that could be to create a special purpose named asset called cp (or something else, does't really matter), that allows any user (not just owners) to create a subasset. Then these assets are not part of the original namespace and this new namespace is much broader. So much so, that creating any number of metaprotocols with this namespace is possible. The simplest of which would be a fully functional global nameservice utilizing punycode.

This type of change would set of a massive land grab and lead to alot of interest and new users entering the counterparty ecosystem.

If there is a major concern with squatting on these assets, a dutch auction in xcp starting at something like 10-20xcp and reducing the cost by 0.01% per block could allow for a slow phase in of a year or so?

[keyuno]

Then these assets are not part of the original namespace and this new namespace is much broader. So much so, that creating any number of metaprotocols with this namespace is possible. The simplest of which would be a fully functional global nameservice utilizing punycode.

If we decide to go the domain route, why not implement a Namecoin-like strategy on Bitcoin using Counterparty with an expiration mechanism for these new 'domains' to allow for more experimentation?

If there is a major concern with squatting on these assets, a dutch auction in xcp starting at something like 10-20xcp and reducing the cost by 0.01% per block could allow for a slow phase in of a year or so?

The expiring domains won't appeal to the collectors' market, and requiring renewal using XCP will help prevent squatting.

Meanwhile, the existing asset class will remain unchanged—set in stone, without unnecessary modifications—as collectibles must be treated with caution and care because their value hinges on their history, and any unwarranted alterations could prove disastrous to their worth.