New address format proposal

🌌 Research Experimental
1

Introduction

We currently have addresses without checksums, addresses with checksums, CDA’s with checksums and parameters for the Accounts module and who knows what the future will bring us. This is not only confusing for the end users but it’s also error prone and prevents the Account module from being adopted since the addresses are not compatible with other software not working with the Account module.

This document describes a proposed solution where we change the output address format to a forward and backward compatible format with support for parameters in the address. This would mean that this would have to be implemented once and should stay the same after that, working towards our goal of creating a production ready implementation.

This proposal is part of my other proposal for a generic higher level client library function implementation; Feel free to check that out as well.

Current situation

  • Take the address without a checksum (SBPQMXALSY9AFWPUFNLGHZBARAJAJFBAGLBNRPDGASYJGKCHOKZNPAFELNVVEWZCKACPNVWEW9SCSURQX)
  • Generate a Kerl hash of that address
  • Take the last 9 trytes of that hash
  • Add those 9 trytes to the address and you have a checksummed address:
    SBPQMXALSY9AFWPUFNLGHZBARAJAJFBAGLBNRPDGASYJGKCHOKZNPAFELNVVEWZCKACPNVWEW9SCSURQXJAXSWOSKC

Proposed situation

  • Take the address without a checksum (SBPQMXALSY9AFWPUFNLGHZBARAJAJFBAGLBNRPDGASYJGKCHOKZNPAFELNVVEWZCKACPNVWEW9SCSURQX)

  • Take all parameters and sort them alphabetically by key

  • Concatenate all keys and values together and convert that string to Trytes

  • Generate a Kerl hash of the address and concatenated parameter trytes

  • Take the last 9 trytes of that hash

  • Add those 9 trytes to the address and you have a checksummed address

  • Add the magnet format and parameters to the URL so it looks like this:
    iota://SBPQMXALSY9AFWPUFNLGHZBARAJAJFBAGLBNRPDGASYJGKCHOKZNPAFELNVVEWZCKACPNVWEW9SCSURQXVUWH9UPJX?multi_use=0&timeout_at=1234578

  • In case of no parameter it looks like this:
    iota://SBPQMXALSY9AFWPUFNLGHZBARAJAJFBAGLBNRPDGASYJGKCHOKZNPAFELNVVEWZCKACPNVWEW9SCSURQXJAXSWOSKC

  • Note that the checksum without parameters is the exact same as in the old situation, allowing this to be backwards compatible.

Code demonstration

An interactive demonstration of the current and proposed generation of checksum/address format can be found here, feel free to check out the code examples and play with it to see how it works:

https://repl.it/repls/AzureMelodicBookmarks

Implications

  • All addresses will be presented as magnet links, integrated software needs to support this/strip this. Benefit of these links are that addresses are easier to distinguish over other hashes and can be intercepted when clicked by Trinity on mobile devices for example.
  • Validation of checksums in existing systems needs to change to facilitatechecksums from addresses with parameters
  • The current Account module addresses are not compatible with this and will need to change, mainly the part where the checksum is generated
  • Everyone needs to adopt this format for it to become the standard
  • If we ever move away from using Kerl or Trytes for address generation this no longer applies.

Comments, suggestions and improvements are very welcome!

1 Like