You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Footnotes
Note that BIP-32 actually use a subscript postfix H to represent hardened derivations so BIPs are already inconsistent 🤷 ↩
The text was updated successfully, but these errors were encountered:
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.
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 👍
In both BIP-32, BIP-44, and CIP-1852 standards, textual representation of a hierarchy of keys use some conventions:
m
represents the master key from which other keys can be derived,1852'
1,/
.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 as1852H/1815H/0H/2/0
. This representation as a few, arguably minor but still annoying problems:1H/2/3
, it's unclear whether this is a derivation from the master key or from an already derived key,root
ormaster_key
value or object and recursively construct a derivation path from it,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.Footnotes
Note that BIP-32 actually use a subscript postfix
H
to represent hardened derivations so BIPs are already inconsistent 🤷 ↩The text was updated successfully, but these errors were encountered: