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
Here I noticed no support for segwit addresses? Also, the output shows segwit derivation path (84h) when address-pkh specified (44h) -> Not OK.
You can generate more test vectors for a particular seed (e.g. lethekit_seed/mnemonic: together mail awful cradle scrub apart hip leader silk slice unusual embark) in https://iancoleman.io/bip39/
@gorazdko I think I had some previous conversations with @ChristopherA and/or @Fonta1n3 where they thought the best default value for the purpose path component was 84. Please advise.
@wolfmcnally I think that came from the discussion that if the output is a complete descriptor (which is what keytool-cli does), and as LetheKit can only do single signature, the default should be 84' crypto-hdkey as that is segwit or its SLIP-132 form of zpub/zprv (I hate SLIP-132, but as future Gordian will not be supporting singlesig except to sweep, and that is what Ledger/Trezor use for segwit, we have to continue to offer it as an option.)
However, we want to focus with LetheKit export not of descriptors but of the crypto-hdkey that is a cosigner, i.e. [48'/0'/0'/2']xpub… and the cosigner's private key [48'/0'/0'/2']xprv…. These two should be the minimal number of clicks, then the singlesig segwit zpub/zprv, then everything else can have more manual entry steps in LetheKit.
Similarly, we need these in seedtool to be the defaults. If you ask for descriptor and don't define a path, it defaults to /84'/0'/0'/0'. If you ask for SLIP-132 and don't offer path offers zpub/zprv form, if you ask for hdkey and don't define path, you get [48'/0'/0'/2']xpub….
I think I had some previous conversations with @ChristopherA and/or @Fonta1n3 where they thought the best default value for the purpose path component was 84. Please advise.
Yes I agree 84 to be default, but there are flags that should change the default value of purpose. Just like here where you made purpose dependent on output-type.
The flags that should change the default purpose are those which hold values: pkh, wpkh, sh-wpkh
Activity
wolfmcnally commentedon Mar 4, 2021
@gorazdko I think I had some previous conversations with @ChristopherA and/or @Fonta1n3 where they thought the best default value for the
purposepath component was 84. Please advise.ChristopherA commentedon Mar 4, 2021
@wolfmcnally I think that came from the discussion that if the output is a complete descriptor (which is what keytool-cli does), and as LetheKit can only do single signature, the default should be 84' crypto-hdkey as that is segwit or its SLIP-132 form of zpub/zprv (I hate SLIP-132, but as future Gordian will not be supporting singlesig except to sweep, and that is what Ledger/Trezor use for segwit, we have to continue to offer it as an option.)
However, we want to focus with LetheKit export not of descriptors but of the crypto-hdkey that is a cosigner, i.e.
[48'/0'/0'/2']xpub…and the cosigner's private key[48'/0'/0'/2']xprv…. These two should be the minimal number of clicks, then the singlesig segwit zpub/zprv, then everything else can have more manual entry steps in LetheKit.Similarly, we need these in seedtool to be the defaults. If you ask for descriptor and don't define a path, it defaults to /84'/0'/0'/0'. If you ask for SLIP-132 and don't offer path offers zpub/zprv form, if you ask for hdkey and don't define path, you get
[48'/0'/0'/2']xpub….gorazdko commentedon Mar 4, 2021
Yes I agree 84 to be default, but there are flags that should change the default value of purpose. Just like here where you made
purposedependent onoutput-type.The flags that should change the default purpose are those which hold values: pkh, wpkh, sh-wpkh
The result I pasted above:
is not wrong, it looks weird though, because 84h is standard for segwit addresses (bech32) and 44h is standard for pkh addresses (base58check)
@wolfmcnally also please test my lethekit PR with keytool and Guardian to confirm that my implementation of cosigner is correct.