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

Support for SLIP132's custom BIP32 prefixes #87

Open
afk11 opened this issue Feb 13, 2019 · 2 comments
Open

Support for SLIP132's custom BIP32 prefixes #87

afk11 opened this issue Feb 13, 2019 · 2 comments

Comments

@afk11
Copy link

afk11 commented Feb 13, 2019

At least trezor and electrum support SLIP132 base58 prefixes for extended keys, which indicate the script type to be derived.

I think it could be worth adding a flags parameter to bip32_key_from_base58[,_alloc], otherwise could expose the behavior through a separate function and avoid the BC break?

@greenaddress
Copy link
Contributor

@afk11 thanks for raising this - agreed, libwally should allow serialization and deserialization for non-bip32
versions. Maybe adding a flag (eg BIP32_ALLOW_ARBITRARY_VERSION) could do the
job, however bip32_key_unserialize (and all the APIs based on that, such as
bip32_key_from_base58) currently do not accept flags in input so that would
require an API change. Before proceeding we should discuss if it's the best way
of doing it.

If needed, at the moment it could be implemented with a small workaround, eg in
py3:

import wallycore as wally

def bip32_from_base58_arbitrary_version(b58key, version, is_private):
    decoded = wally.base58check_to_bytes(b58key)
    assert decoded[:4] == version
    bip32_version = wally.BIP32_VER_MAIN_PRIVATE if is_private else wally.BIP32_VER_MAIN_PUBLIC
    return wally.bip32_key_unserialize((bip32_version).to_bytes(4, 'big') + decoded[4:])

def bip32_to_base58_arbitrary_version(xkey, flags, version):
    encoded = wally.bip32_key_serialize(xkey, flags)
    return wally.base58check_from_bytes(version + encoded[4:])

@afk11
Copy link
Author

afk11 commented Feb 27, 2019

Thanks for the response!

I experimented with allowing developer provided definitions, and adding a pointer to a definition on ext_key. If no definition is set, the previous code working with BIP32_VER_MAIN_PUBLIC/BIP32_VER_MAIN_PRIVATE/etc is used: master...afk11:bip32-versions

I had the same thoughts regarding bip32_key_unserialize, but since ^ adds extra arguments I went with separate functions for now. I'm pretty sure bip32_key_unserialize could populate the definition for whatever network it determines, and hence we could rule out special cases for keys with and without definitions.

Let me know what you think anyway!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants