Use standards-compliant textual representation of key derivation

[abailly]

In both BIP-32, BIP-44, and CIP-1852 standards, textual representation of a hierarchy of keys use some conventions:

• the prefix m represents the master key from which other keys can be derived,
• hardened key derivation is denoted by a single quote character following the index, eg 1852' [^1],
• indices are separated by forward slash character /.

Full CIP-1852 compliant key derivation of a staking key would be expressed as ie. m / 1852' / 1815' / 0' / 2 / 0.

In the cardano-address CLI we use a different textual representation: The above derivation would be represented as 1852H/1815H/0H/2/0. This representation as a few, arguably minor but still annoying problems:

• it cannot distinguish between absolute and relative derivations: When one writes 1H/2/3, it's unclear whether this is a derivation from the master key or from an already derived key,
• it does not align with encoding in a programming language which would usually explicitly use a root or master_key value or object and recursively construct a derivation path from it,
• it's different from standards.

I would like to propose that we align the textual representation used in cardano-addresses to the one used in industry standards, while preserving backward compatibility to not break existing tools and workflows.

[^1]: Note that BIP-32 actually use a subscript postfix H to represent hardened derivations so BIPs are already inconsistent 🤷

[abailly]

@paweljakubas @Crypto2099 @disassembler Any thoughts on this?

[Crypto2099]

The use of the apostrophe ' seems consistent with BIP-44 while the use of the subscript _H seems consistent with BIP-32. CIP-1852 fails to define the definition of the apostrophe or subscript H which is an oversight itself IMO. However, given that CIP-1852 uses the apostrophe syntax I believe that it stands to reason that other tooling within the ecosystem should use labels that are consistent with our own CIPs and would support beginning to move cardano-addresses towards alignment w/ CIP-1852.

I strongly agree that the m should be present at the front when displaying as well to show that it is root/master derivation path.

[paweljakubas]

I agree with the proposal to have this supported (modulo we will also support "old" style for backward compability). I am happy to handle this ticket :+1: