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
We should always err on the side of not making new serialization formats. Can we achieve our UX goals with BIP-44, if not are there commonly supported extentions that do support that. If neither of these are possible, can we use parts of BIP-44 like SLIP-44 registered coin types?
The text was updated successfully, but these errors were encountered:
One thing to consider as well is that we can do BIP-44 compatible key derivation strings, but I don't believe we can do BIP-39 compatible derivations, so the public keys won't be developed in a predictable way for now, but there exists a PoC implementation that does this.
The main issue I see with BIP-44 is that we wouldn't be able to include domains, which we need to separate accounts used by different apps/domains. I think a more flexible key derivation structure could benefit the user experience overall, even for future use cases, so I'd be in favor of keeping it as described here.
I've proposed a way of doing key derivations in PR-15. Serhii quite reasonably pointed out that I'm largely reinventing BIP-44.
We should always err on the side of not making new serialization formats. Can we achieve our UX goals with BIP-44, if not are there commonly supported extentions that do support that. If neither of these are possible, can we use parts of BIP-44 like SLIP-44 registered coin types?
The text was updated successfully, but these errors were encountered: