Technical Implementation of Subasset Encoding

Development
1

Details about the new subasset issuance type:

  • The ID will be 21
  • The encoded format will be >QQ?{}s{}s. This is an Asset ID (8 bytes), Quantity (8 bytes), Divisibilty (1 byte), Asset Longname (variable), Description (variable). Description is optional.

Callable assets are disabled so there is no reason to include the 12 bytes allotted to callable information at this time.

Option 1 - New Subasset Issuance Parsing Code

  • Create new code at subassetissuance.py
  • This would duplicate some code and keep subasset issuance logic separate from issuance logic
  • Refactor some of the shared issuance logic into a separate utility file

Option 2 - Merge Subasset Issuance into the current Issuance Parsing Code

  • Modify issuance.py to handle both types ID 20 and 21.
  • If the ID is type 21, use the new encoded format.

BONUS - Allow type 21 to handle all issuances

  • Create a new issuance code file: issuance2.py
  • Type 21 will not include the 12 bytes of unused callable information
  • Type 21 can handle all types of issuances - normal, subasset, reissuances, etc.
  • If the Asset Longname is empty, treat the transaction as a normal issuance
  • Type 20 will still be supported for legacy clients.
2

I’m going with option 2 here.

The actual format is >QQ?B{}s{}s where B is the length of the (compacted) subasset name.

I’m compacting the name of the subasset (using a base 68 encoding algorithm) to save a few bytes. A typical 13 character subasset names takes up 10 bytes instead of 13.

Reissuances will continue to use the existing transaction format (type 20).