Creating a standard for the "BIP44 path derivation" of ICON addresses (discussion)

This thread is created to separate the discussion in this thread:

The subject to discuss is the creation of a BIP44 standard in regards to coin_type and derivation paths for ICON.

Background and reasoning behind this post.

Creating an standard for the BIP44 coin_type and derivation paths for ICX wallets will allow for compatibility for wallet generation based on mnemonic seeds across the ICON ecosystem. The benefit of this are the following:

  • Allow backup compatibility between wallets that generate addresses based on mnemonic seeds.
  • Create a seamless user experience in web apps that allow for users to login or sign transactions with ledger devices. To explain this point a bit further, currently to use a ledger device you have to use either ICONex or Hana as middlewares for the ledger device, these wallets will connect to the ledger device, supply a BIP44 derivation path and the ledger device will reply with a public address. If lets say Balanced implements ledger support for its users and supply a different BIP44 derivation path to the ledger device, the wallet addresses that the user will see in Balanced will be different than the wallets that the user will see in ICONex or Hana, even if the ledger device is the same.

here are a couple of links where ive been having these discussions before posting this thread:

https://github.com/icon-project/ledger-app-icx/issues/23
https://github.com/icon-project/devportal/issues/35

2 Likes

The “proper” BIP44 path (bips/bip-0044.mediawiki at master · bitcoin/bips · GitHub) for ICON addresses (which we use for Hana seed phrase wallets) should be:

m/44'/74'/0'/0/{index}

Note that the coin type is 74 as defined by the known BIP44 coin types, and that the last two parts of the path aren’t using “hardened derivation” (indicated by the apostrophes ').

However for deriving Ledger addresses, the path should be:

m/44'/4801368'/0'/0'/{index}'

Note the non-standard coin type of 4801368, and that all parts of the path are using “hardened derivation”, which again isn’t standard for BIP44.

I suspect that the coin type may have been set it the ledger-app-icx codebase before there was an official BIP44 coin type. The rest of the derivation path is maintained for legacy reasons. If one or more wallets wanted to use a different derivation path for Ledger ICX addresses, they would likely need to include a “use legacy path” or similar option to maintain compatibility.

1 Like

thank you @bb_reliantnode for participating in the discussion.

as a summary I would like to point out the following:

  • This is the document detailing the specifications of the BIP-44 link

  • This is the document detailing the different coin_type for each coin, in which ICX has a coin_type of 74. SLIP-44 link.

  • The proposed IIP should detail both coin_type of 4801368 and the derivation path m/44'/4801368'/0'/0'/{index}' with hardened derivation for legacy purposes and the standard should be coin_type of 74 with derivation path m/44'/74'/0'/0/{index} to adhere to the SLIP-44 standard.

If everyone agrees we can start writing a draft of the proposal with the provided details.

Since we have a current CPS project being funded to add support for ICX in the Ledger live software wallet, im going to contact the ICONDAO team and ask them to give us feedback in this discussion.

I believe that if we successfully create an IIP standard we can then propose and update to the @ledgerHQ/app-icx and properly create an NPM package for it which is something we currently dont have.

1 Like

I agree with all of that, it’s definitely worthwhile coordinating with the team working on the CPS project to add Ledger Live support. If they end up using a different derivation path for Ledger Live addresses, then we’ll need to add support to Hana for that path too. So that if users add Ledger Live assets they’ll be able to see them in Hana too.

I also agree with getting the NPM package added. I was hoping the CPS project team would be doing that, but if not we should see what’s required to get it done.

@espanicon @bb_reliantnode Sorry y’all for repeated material, but linking the forum post about the updated IIP process here as well for convenience

Forum post

the team behind the ledger live CPS proposal has been contacted, they are interested in this proposal so I will be waiting for their comments to continue moving forward this proposal.

---
iip: <to be assigned>
title: BIP-44 Path for derivation of ICON address from mnemonic seeds.
author: Fidel (github.com/FidelVe), Ben (github.com/bkbooth), Eric (github.com/han-so1omon)
discussions-to: https://forum.icon.community/t/creating-a-standard-for-the-bip44-path-derivation-of-icon-addresses-discussion/2702
status: Draft
type: Informational
created: 2022-06-04T08:21:46+0000
---

Simple Summary

A defined BIP-44 path for derivation of ICON addresses from mnemonic seeds.

Abstract

BIP-44 is the standard that describes the derivation paths that Hierarchical Deterministic (HD) wallets (as defined in BIP-32) can use to derive wallet addresses. It structure defines levels in the paths to define coin types, accounts, chain (change level) and addresses, using different paths when deriving wallets from mnemonic seeds will result in different addresses and for this reason each blockchain defines a path to be used as the standard when generating wallet addresses in their chains.

Motivation

Creating an standard for the BIP44 coin_type and derivation paths for ICON wallets will allow for compatibility for wallet generation based on mnemonic seeds across the ICON ecosystem. The benefit of this are the following:

  • Allow backup compatibility between wallets that generate addresses based on mnemonic seeds.
  • Create a seamless user experience in web apps that allow for users to login or sign transactions with ledger devices or any other Hierarchical Deterministic wallet.

Specification

This specification describes the following derivation paths:

  • Standard derivation path: This derivation path uses the guidelines described in the BIP-44 and SLIP-44 to maintain the ICON Ecosystem in line with the industry standards and should be the one used for generating new ICON wallet addresses.

  • Legacy derivation path: This derivation path purpose is to maintain backwards compatibility for ICON addresses generated by ICONex via Ledger devices.

Developers of Hierarchical Deterministic wallet in the ICON Ecosystem should use the Standard derivation path to generate new ICON addresses to their users and use the Legacy derivation path as an option when importing a mnemonic seed to allow backward compatibility.

Developers of web applications that have an interface for user login via ICON wallets should present both Standard and Legacy derivation paths to allow the users to choose from.

The following is the path levels described in the BIP-44 specification.

m / purpose' / coin_type' / account' / change / address_index

Apostrophe in the path indicates that BIP32 hardened derivation is used.

As defined in BIP-44 purpose is a constant set to 44', this document defines the values for the subsequent levels (coin_type' / account' / change / address_index).

Path levels for Standard and Legacy.

  • Standard: With a coin_type of 74', hardened derivation for account' and non-hardened derivation for change and address_index. (example of initial path: m / 44' / 74'/ 0' / 0 / 0).
  • Legacy with a coin_type of 4801368' and hardened derivations for account', change' and address_index'. (example of initial path: m / 44' / 4801368'/ 0' / 0' / 0')

Account Discovery

The general recommendation is to follow the specifications described in the Account discovery section of the BIP-44 document, which described the process to generate multiple accounts with one master seed and multiple addresses for each account.

For general purposes and for the sake of simplicity this document recommends the use of the following levels in the path for both Standard and Legacy paths and derive systematically by increasing the level address_index as follow:

  • Standard: m / 44' / 74'/ 0' / 0 / {index}
  • Legacy: m / 44' /4801368'/ 0' / 0' / {index}'

Rationale

Backwards Compatibility

Test Cases

Implementation

Copyright

Copyright and related rights waived via CC0.

2 Likes

this is the first draft for this IIP, any feedback is appreciated. Thanks to @bb_reliantnode and @errcsool for their collaborations!

standard proposal accepted and published as IIP-48

thanks everyone for their collaborations.

@espanicon This is my bad, but this has been merged without any discussion in Github. That should not typically occur. @bb_reliantnode Is there any further discussion about this that you would like to see prior to acceptance?

Thanks @errcsool, this was fine to merge/accept from my perspective. I shared all of my thoughts beforehand on Discord and in this thread and I think @espanicon did will writing this up and covering all of my feedback.

1 Like

Ok, cool. I’ve noticed that it has been accepted as a Draft as well, so it’s all good. Thanks!