* 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
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
2017-09-05 19:00 [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts Kabuto Samourai
@ 2017-09-06 9:26 ` Thomas Voegtlin
2017-09-06 13:47 ` Kabuto Samourai
2017-09-07 19:02 ` Luke Dashjr
1 sibling, 1 reply; 10+ messages in thread
From: Thomas Voegtlin @ 2017-09-06 9:26 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
On 05.09.2017 21:00, Kabuto Samourai wrote:
>
> 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?
>
I agree that this would make sense if we had done it from the start.
However, fixing that now might be difficult.
My "xyz" proposal extends the current format in a way that is very easy
to deploy, because existing software will require minimal changes.
However, if we eliminate the p2sh ambiguity now, wallets will need to
add extra safeguards, in order to prevent scenarios that are currently
allowed, and they will need to handle legacy xpub/xprv differently than
ypub and zpub. This would take much more time to deploy.
In addition, consensus might be more difficult to reach on that; I guess
not all developers will not agree that removing that ambiguity is
useful. Since there is an infinity of possible P2SH scripts, it will
never be possible to remove ambiguity from a master key associated to a
P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
strong.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
2017-09-06 9:26 ` Thomas Voegtlin
@ 2017-09-06 13:47 ` Kabuto Samourai
0 siblings, 0 replies; 10+ messages in thread
From: Kabuto Samourai @ 2017-09-06 13:47 UTC (permalink / raw)
To: Thomas Voegtlin, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]
> In addition, consensus might be more difficult to reach on that
Let's move forward with the simplest solution that solves the problem and
achieves consensus! Version bytes {x,y,z} fits the bill.
On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> On 05.09.2017 21:00, Kabuto Samourai wrote:
> >
> > 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?
> >
>
> I agree that this would make sense if we had done it from the start.
> However, fixing that now might be difficult.
>
> My "xyz" proposal extends the current format in a way that is very easy
> to deploy, because existing software will require minimal changes.
> However, if we eliminate the p2sh ambiguity now, wallets will need to
> add extra safeguards, in order to prevent scenarios that are currently
> allowed, and they will need to handle legacy xpub/xprv differently than
> ypub and zpub. This would take much more time to deploy.
>
> In addition, consensus might be more difficult to reach on that; I guess
> not all developers will not agree that removing that ambiguity is
> useful. Since there is an infinity of possible P2SH scripts, it will
> never be possible to remove ambiguity from a master key associated to a
> P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
> strong.
> _______________________________________________
> 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: 2755 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
2017-09-05 19:00 [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts Kabuto Samourai
2017-09-06 9:26 ` Thomas Voegtlin
@ 2017-09-07 19:02 ` Luke Dashjr
1 sibling, 0 replies; 10+ messages in thread
From: Luke Dashjr @ 2017-09-07 19:02 UTC (permalink / raw)
To: bitcoin-dev, Kabuto Samourai
On Tuesday 05 September 2017 15:00:04 Kabuto Samourai via bitcoin-dev wrote:
> 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.
In that case, I think we should go back to the proposal I started with in
March...
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013726.html
This handles not only simple HD seeds, but also multisig HD and such.
Luke
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
2017-09-05 17:03 ` Luke Dashjr
2017-09-05 18:09 ` Thomas Voegtlin
@ 2017-09-06 17:02 ` Pavol Rusnak
1 sibling, 0 replies; 10+ messages in thread
From: Pavol Rusnak @ 2017-09-06 17:02 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion, Thomas Voegtlin
On 05/09/17 19:03, Luke Dashjr via bitcoin-dev wrote:
> 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...
If I were designing the serialization format today, I would drop the
fingerprint and expand child number to full BIP32 path. Good thing is
that we already have depth, so we know how long the BIP32 path would be.
So I suggest the following:
4 byte: version bytes
1 byte: depth
depth * 4 bytes: bip32 path
32 bytes
33 bytes
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
2017-09-05 10:25 Thomas Voegtlin
2017-09-05 15:44 ` Pavol Rusnak
2017-09-05 17:03 ` Luke Dashjr
@ 2017-09-05 22:13 ` Andreas Schildbach
2 siblings, 0 replies; 10+ messages in thread
From: Andreas Schildbach @ 2017-09-05 22:13 UTC (permalink / raw)
To: bitcoin-dev
Generally I like the idea, but maybe we should come up with a
(Bech32-based?) new standard that also includes the key birthdate (aka
"wallet birthdate").
Also I heard Core will mix addresses of all types on the same HD chain.
What prefix would it pick? "*pub"?
On 09/05/2017 12:25 PM, Thomas Voegtlin via bitcoin-dev wrote:
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
2017-09-05 17:03 ` Luke Dashjr
@ 2017-09-05 18:09 ` Thomas Voegtlin
2017-09-06 17:02 ` Pavol Rusnak
1 sibling, 0 replies; 10+ messages in thread
From: Thomas Voegtlin @ 2017-09-05 18:09 UTC (permalink / raw)
To: Luke Dashjr, bitcoin-dev
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
2017-09-05 10:25 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
2 siblings, 2 replies; 10+ messages in thread
From: Luke Dashjr @ 2017-09-05 17:03 UTC (permalink / raw)
To: bitcoin-dev, Thomas Voegtlin
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts
2017-09-05 10:25 Thomas Voegtlin
@ 2017-09-05 15:44 ` Pavol Rusnak
2017-09-05 17:03 ` Luke Dashjr
2017-09-05 22:13 ` Andreas Schildbach
2 siblings, 0 replies; 10+ messages in thread
From: Pavol Rusnak @ 2017-09-05 15:44 UTC (permalink / raw)
To: Thomas Voegtlin, Bitcoin Protocol Discussion
On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> ========== =========== ===================================
> 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.
I used this argument for mnemonic/seed, not xpub/xprv. I am fine with
this proposal of yours, so don't worry.
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
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 19:00 [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts Kabuto Samourai
2017-09-06 9:26 ` Thomas Voegtlin
2017-09-06 13:47 ` Kabuto Samourai
2017-09-07 19:02 ` Luke Dashjr
-- strict thread matches above, loose matches on Subject: below --
2017-09-05 10:25 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox