Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-05 📝 Original message:On Tuesday 05 September ...
📅 Original date posted:2017-09-05
📝 Original message:On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev wrote:
> I have heard the argument that xpub/xprv serialization is a format for
> keys, and that it should not be used to encode how these keys are used.
> However, the very existence of version bytes, and the fact that they are
> used to signal whether keys will be used on testnet or mainnet goes
> against that argument.
>
> If we do not signal the script type in the version bytes, I believe
> wallet developers are going to use dirtier tricks, such as the bip32
> child number field in combination with bip43/bip44/bip49.
I think it makes more sense to use a child number field for this purpose.
It seems desirable to use the same seed for all different script formats...
As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
really doesn't make sense to differentiate segwit specifically.
Luke
📝 Original message:On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev wrote:
> I have heard the argument that xpub/xprv serialization is a format for
> keys, and that it should not be used to encode how these keys are used.
> However, the very existence of version bytes, and the fact that they are
> used to signal whether keys will be used on testnet or mainnet goes
> against that argument.
>
> If we do not signal the script type in the version bytes, I believe
> wallet developers are going to use dirtier tricks, such as the bip32
> child number field in combination with bip43/bip44/bip49.
I think it makes more sense to use a child number field for this purpose.
It seems desirable to use the same seed for all different script formats...
As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
really doesn't make sense to differentiate segwit specifically.
Luke