Thomas Voegtlin [ARCHIVE] on Nostr: š
Original date posted:2017-09-07 š Original message:On 07.09.2017 18:23, Pavol ...
š
Original date posted:2017-09-07
š Original message:On 07.09.2017 18:23, Pavol Rusnak wrote:
> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
>> A solution is still needed to wallets who do not wish to use BIP43
>
> What if we added another byte field OutputType for wallets that do not
> follow BIP43?
>
> 0x00 - P2PKH output type
> 0x01 - P2WPKH-in-P2SH output type
> 0x02 - native Segwit output type
>
> Would that work for you?
>
> The question is whether this field should be present only if depth==0x00
> or at all times. What is your suggestion, Thomas?
>
well, in my initial proposal, I wrote that this value should be user
visible. That is why I used version bytes. If you create an extra byte
field, and then use base58 or bech32 encoding, the value will not be
user visible anymore.
The initial implementation of segwit xpub/xprv in Electrum used a flag
that was not user visible (I added 1 to the bip32 version bytes, which
leaves the xpub/xprv prefix unchanged). I have experimented with that
invisible flag for more than 6 months now, and I am now convinced that
it is better to make that flag user visible.
The reason is that when users create wallets with multisig scripts, they
need to combine several master public keys. However, these master public
keys should all be of the same type: it would not make sense to create a
2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By
imposing that all master keys are of the same type, we ensure that all
cosigners agree on the script type that will be used to derive addresses.
In other words, if users are exposed to master keys and need to
manipulate them, it is better to let them see what they are doing.
OTOH if you do not plan to expose your users to these keys, you probably
do not need a serialization format.
Published at
2023-06-07 18:05:32Event JSON
{
"id": "b6cc2965c6377753d32761cb2b2e199ba81abe681ae38185d72f579b422b54e4",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686161132,
"kind": 1,
"tags": [
[
"e",
"8b6c82e376bdda93cb2f70dd4782d9cc9d7453907841b893f7135515b4f67b4c",
"",
"root"
],
[
"e",
"37f2cebb44b2616fb75a141c11906396d65852b5ca945158ad4674956f3741e4",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "š
Original date posted:2017-09-07\nš Original message:On 07.09.2017 18:23, Pavol Rusnak wrote:\n\u003e On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:\n\u003e\u003e A solution is still needed to wallets who do not wish to use BIP43\n\u003e \n\u003e What if we added another byte field OutputType for wallets that do not\n\u003e follow BIP43?\n\u003e \n\u003e 0x00 - P2PKH output type\n\u003e 0x01 - P2WPKH-in-P2SH output type\n\u003e 0x02 - native Segwit output type\n\u003e \n\u003e Would that work for you?\n\u003e \n\u003e The question is whether this field should be present only if depth==0x00\n\u003e or at all times. What is your suggestion, Thomas?\n\u003e \n\n\nwell, in my initial proposal, I wrote that this value should be user\nvisible. That is why I used version bytes. If you create an extra byte\nfield, and then use base58 or bech32 encoding, the value will not be\nuser visible anymore.\n\nThe initial implementation of segwit xpub/xprv in Electrum used a flag\nthat was not user visible (I added 1 to the bip32 version bytes, which\nleaves the xpub/xprv prefix unchanged). I have experimented with that\ninvisible flag for more than 6 months now, and I am now convinced that\nit is better to make that flag user visible.\n\nThe reason is that when users create wallets with multisig scripts, they\nneed to combine several master public keys. However, these master public\nkeys should all be of the same type: it would not make sense to create a\n2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By\nimposing that all master keys are of the same type, we ensure that all\ncosigners agree on the script type that will be used to derive addresses.\n\nIn other words, if users are exposed to master keys and need to\nmanipulate them, it is better to let them see what they are doing.\n\nOTOH if you do not plan to expose your users to these keys, you probably\ndo not need a serialization format.",
"sig": "9aaa495295c50bf1b105818e23c83fbeb89aec713b1e3e11a4fe91c279692d63e4f251c5d431a903b538632bd802da5873930a08e126674ac0ff0f636bd6aa1a"
}