public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
@ 2017-09-05 10:25 Thomas Voegtlin
  2017-09-05 15:44 ` Pavol Rusnak
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Thomas Voegtlin @ 2017-09-05 10:25 UTC (permalink / raw)
  To: bitcoin-dev

BIP32 extended public/private keys have version bytes that result in the
user visible xpub/xprv prefix. The BIP's recommendation is to use
different version bytes for other networks (such as tpub/tprv for testnet)

I would like to use additional version bytes to indicate the type of
output script used with the public keys.

I believe the change should be user visible, because users are exposed
to master public keys. I propose the following prefixes:

========== =========== ===================================
Version    Prefix      Description
========== =========== ===================================
0x0488ade4 xprv        P2PKH or P2SH
0x0488b21e xpub        P2PKH or P2SH
0x049d7878 yprv        (P2WPKH or P2WSH) nested in P2SH
0x049d7cb2 ypub        (P2WPKH or P2WSH) nested in P2SH
0x04b2430c zprv        P2WPKH or P2WSH
0x04b24746 zpub        P2WPKH or P2WSH
========== =========== ===================================
(source: http://docs.electrum.org/en/latest/seedphrase.html)

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.


Thomas


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
@ 2017-09-05 19:00 Kabuto Samourai
  2017-09-06  9:26 ` Thomas Voegtlin
  2017-09-07 19:02 ` Luke Dashjr
  0 siblings, 2 replies; 10+ messages in thread
From: Kabuto Samourai @ 2017-09-05 19:00 UTC (permalink / raw)
  To: Thomas Voegtlin, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

We support a change to the version bits of the HD serialization that will
inform the receiving utility of the exact derivation method used for the
pubkeys. Third-parties handling xpubs must not require additional
information from the user about the derivation path or serialization format
of the addresses under that xpub. When you have to ask, "Is this a SegWit
xpub?" then you've already lost.

Avoiding a total UX nightmare is in everyone's interests.

I think Luke and Thomas may be talking past one another. When exporting a
root master HD seed, encoding the {x,y,z}{pub,prv} distinctions makes no
sense, as the root seed should derive all paths for all coins. Wallets may
need additional code to discover which paths have been used when importing
a root seed. But when exporting / importing an account-level seed for
watch-only and receive address generation, changing the serialization
version bytes is appropriate and (in our view) essential to avoid loss of
funds.

The Electrum approach is nice but may not go far enough, as xpub and zpub
both list "P2PKH or P2SH." Why not expand the number of version prefixes to
eliminate the ambiguity?


On Tue, Sep 5, 2017 at 1:09 PM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On 05.09.2017 19:03, Luke Dashjr wrote:
>
> > It seems desirable to use the same seed for all different script
> formats...
>
> That does not seem desirable to everybody.
>
> If you want to guarantee that users will be able to recover all their
> funds from their mnemonic seed (and that is what they expect), then
> wallets must implement all script formats, even the ones that are
> deprecated. In addition, the list of script formats that must be
> supported is not defined in advance, but it keeps growing. This makes
> wallet implementation increasingly difficult. In the long run, seed
> portability is guaranteed to fail in such a system.
>
> > As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> > really doesn't make sense to differentiate segwit specifically.
>
> That's not a reason. The fact that xpub/xprv can be used for both P2PKH
> and P2SH has already resulted in users receiving coins on addresses they
> do not control.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
-Kabuto

PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A  B065 320F B934 A79B 6A99

[-- Attachment #2: Type: text/html, Size: 3426 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-09-07 19:02 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-05 10:25 [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts Thomas Voegtlin
2017-09-05 15:44 ` Pavol Rusnak
2017-09-05 17:03 ` Luke Dashjr
2017-09-05 18:09   ` Thomas Voegtlin
2017-09-06 17:02   ` Pavol Rusnak
2017-09-05 22:13 ` Andreas Schildbach
2017-09-05 19:00 Kabuto Samourai
2017-09-06  9:26 ` Thomas Voegtlin
2017-09-06 13:47   ` Kabuto Samourai
2017-09-07 19:02 ` Luke Dashjr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox