Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use standards-compliant textual representation of key derivation #287

Open
abailly opened this issue Dec 14, 2024 · 3 comments
Open

Use standards-compliant textual representation of key derivation #287

abailly opened this issue Dec 14, 2024 · 3 comments
Assignees
Labels
haskell PR:ADDING FEATURE Mark a PR as adding a new feature, for auto-generated CHANGELOG

Comments

@abailly
Copy link
Contributor

abailly commented Dec 14, 2024

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

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

@abailly
Copy link
Contributor Author

abailly commented Dec 30, 2024

@paweljakubas @Crypto2099 @disassembler Any thoughts on this?

@Crypto2099
Copy link
Contributor

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
Copy link
Collaborator

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 👍

@paweljakubas paweljakubas self-assigned this Jan 2, 2025
@paweljakubas paweljakubas added haskell PR:ADDING FEATURE Mark a PR as adding a new feature, for auto-generated CHANGELOG labels Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
haskell PR:ADDING FEATURE Mark a PR as adding a new feature, for auto-generated CHANGELOG
Projects
None yet
Development

No branches or pull requests

3 participants