[bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak]

The discussion about changing bip32 version bytes for SegWit got me
thinking and I ended up with what I think is the best proposal:

https://github.com/satoshilabs/slips/blob/master/slip-0032.md

(It is hosted in SL repo for now, but if there is will, I would love to
have this added to BIP repo as an extension to BIP32)

Feel free to comment.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Kabuto Samourai]

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

Thanks for the proposal. Aside from potential privacy implications of
revealing the derivation path for non BIP-44, 45, 49 HD nodes, this scheme
is superior to the alternate {x,y,z}pub idea. Since coin_type is part of
the path, the 'xpub' prefix may be shared across all coins if they so
choose. This format provides lock-in for BIP-49 going forward and opens the
door for a parallel native-SegWit BIP.

The birthday field is interesting. Could you provide some motivation for
its inclusion?

Could you also add some test vectors?

There are a few minor grammar / spelling errors, but we can nitpick those
after this goes to the pull request stage on bitcoin/bips.

On Wed, Sep 6, 2017 at 5:29 PM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
>
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
>
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
>
> Feel free to comment.
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> _______________________________________________
> 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: 2530 bytes --]

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Thomas Voegtlin]

On 07.09.2017 00:29, Pavol Rusnak via bitcoin-dev wrote:
> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
> 
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
> 
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
> 
> Feel free to comment.
> 


Your proposal forces wallets to use the derivation path in order to
determine the type of output script. it will work only in the context of
BIP43.

Therefore, it should not be proposed as a BIP32 improvement, but as a
improvement of BIP43.

A solution is still needed to wallets who do not wish to use BIP43

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak]

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?

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak]

On 07/09/17 05:52, Kabuto Samourai wrote:
> The birthday field is interesting. Could you provide some motivation for
> its inclusion?

Birthday is something SPV wallet developers have been wanting for years.
It helps them with the initial scan, so SPV wallet does not have to
download every block in the blockchain, but only the ones after birthday.

> Could you also add some test vectors?

I will add some test vectors, when we agree this is the way to go.

> There are a few minor grammar / spelling errors, but we can nitpick
> those after this goes to the pull request stage on bitcoin/bips.

+1

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Kabuto Samourai]

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

> Birthday

Why not make this block height, rather than a timestamp?

On Thu, Sep 7, 2017 at 11:25 AM, Pavol Rusnak <stick@satoshilabs.com> wrote:

> On 07/09/17 05:52, Kabuto Samourai wrote:
> > The birthday field is interesting. Could you provide some motivation for
> > its inclusion?
>
> Birthday is something SPV wallet developers have been wanting for years.
> It helps them with the initial scan, so SPV wallet does not have to
> download every block in the blockchain, but only the ones after birthday.
>
> > Could you also add some test vectors?
>
> I will add some test vectors, when we agree this is the way to go.
>
> > There are a few minor grammar / spelling errors, but we can nitpick
> > those after this goes to the pull request stage on bitcoin/bips.
>
> +1
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>



-- 
-Kabuto

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

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

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Kabuto Samourai]

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

OutputType byte solution is nearly equivalent to {x,y,z} and adds redundant
data. Implementations could erroneously (maliciously) assign the wrong
output type for the given purpose field.

We could reduce the scope of this improvement to BIP43, as suggested by
Thomas. BIP32-generic wallets may implement something else.

On Thu, Sep 7, 2017 at 11:23 AM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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?
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> _______________________________________________
> 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: 2187 bytes --]

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak]

On 07/09/17 18:30, Kabuto Samourai wrote:
> Why not make this block height, rather than a timestamp?

Blockheight depends on the chain. XPUB is not tied to particular
chain/coin.

Also there are already cryptocurrencies that do not use blockchain, but
directed acyclic graph (DAG) for storing transactions. So it would not
be obvious what number to use as a blockheight.

OTOH all blockchains contain timestamps in their blocks, so we can use that.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Jonas Schnelli]

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

Thanks for the proposal.

Three points it could see as possible improvements:

1.
From what I know, the exact birthday in seconds doesn’t matter that much therefore it may be possible to just use 13 or 16bits to create a representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157 years.
Always round down to the beginning of the week when the key was created.
But not sure if it’s worth to save ~two bytes for that.
Also not sure if the key-birthday in seconds could have a security or privacy implication (week maybe better).

2.
Would it make sense to have special depth bytes that directly implies it’s a BIP44 master key (and therefore avoid the bip32 path serialisation)? I know some „centralised“ table need to be available for that which may be not a good idea. But maybe the BIP could reserve a couple of depth-bytes (maybe 0xF0 to 0xFF) for predefined paths.

3.
Would adding a version bit make sense to allow future extensions?


/jonas


> Am 06.09.2017 um 15:29 schrieb Pavol Rusnak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
> 
> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
> 
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
> 
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
> 
> Feel free to comment.
> 
> --
> Best Regards / S pozdravom,
> 
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Peter Todd]

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

On Thu, Sep 07, 2017 at 06:37:19PM +0200, Pavol Rusnak via bitcoin-dev wrote:
> On 07/09/17 18:30, Kabuto Samourai wrote:
> > Why not make this block height, rather than a timestamp?
> 
> Blockheight depends on the chain. XPUB is not tied to particular
> chain/coin.
> 
> Also there are already cryptocurrencies that do not use blockchain, but
> directed acyclic graph (DAG) for storing transactions. So it would not
> be obvious what number to use as a blockheight.
> 
> OTOH all blockchains contain timestamps in their blocks, so we can use that.

More to the point, even for the blockchains that don't contain timestamps in
their blocks, their blocks do exist in our spacetime continum and thus are
created at a specific point in time. :)

If someone does however come up with an example of a blockchain that does not
occupy our spacetime continum, I'd love to hear about it!

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Peter Todd]

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

On Thu, Sep 07, 2017 at 09:47:16AM -0700, Jonas Schnelli via bitcoin-dev wrote:
> Thanks for the proposal.
> 
> Three points it could see as possible improvements:
> 
> 1.
> From what I know, the exact birthday in seconds doesn’t matter that much therefore it may be possible to just use 13 or 16bits to create a representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157 years.
> Always round down to the beginning of the week when the key was created.
> But not sure if it’s worth to save ~two bytes for that.
> Also not sure if the key-birthday in seconds could have a security or privacy implication (week maybe better).

Note how private key birthday is a potential privacy issue in certain cases.
Rare of course, because usually you don't release your private keys! But users
will on occasion have those keys be compromised.

Personally, I'd advocate rounding down to month-level resolution, as that
should be both enough to handle any likely reorg scenario, and it's still a
precision that won't add much extra scanning ot any reasonably old (~1yr)
wallet.

Note also how if transactions created with private keys in a seed use
nLockTime, you can ensure coins won't exist in a block older than the seed
birthday by simply ensuring that nLockTime is set to a more recent date then
that birthday under all circumstances.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak]

[-- Attachment #1.1: Type: text/plain, Size: 1731 bytes --]

On 07/09/17 18:47, Jonas Schnelli wrote:
> But not sure if it’s worth to save ~two bytes for that.

I think it's not worth complicating the field just to save two bytes.

But if we agree (for privacy reasons) that resolution of this field
should be reduced to week-level (as suggested by Jonas) or month-level
(as sugested by Peter), we could use just 16 bits for this.

TBH I think TREZOR will provide hardcoded constant for this field
(1.1.2014 for all its P2PKH xpubs and 1.8.2017 for all its
P2WPKH-in-P2SH xpubs). So no privacy is lost in this case, but if we
want to ENFORCE this on BIP level, we should decrease the resolution.

> 2.
> Would it make sense to have special depth bytes that directly implies it’s a BIP44 master key (and therefore avoid the bip32 path serialisation)? I know some „centralised“ table need to be available for that which may be not a good idea. But maybe the BIP could reserve a couple of depth-bytes (maybe 0xF0 to 0xFF) for predefined paths.

I think this is exactly what Thomas meant by "wallet developers are
going to use dirtier tricks" in his email, that's why I specifically
tried to avoid this. I see no good reason to do this, unless we want to
save some bytes and I don't think we are in need of doing this.

> 3.
> Would adding a version bit make sense to allow future extensions?

I think changing the human-readable part is the way to go. That way the
wallet can immediately say if it understands the format or not, without
parsing the binary data contents. Version bits were introduced in older
standards, because there was no such thing as human-readable prefix.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Andreas Schildbach]

On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev 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?

I think that would work.

> The question is whether this field should be present only if depth==0x00
> or at all times. What is your suggestion, Thomas?

In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
we need this field. I think it should always be present if a chain is
limited to a certain script type.

There is however the case where even on one chain, script types are
mixed. In this case the field should be omitted and the wallet needs to
scan for all (known) types. Afaik Bitcoin Core is taking this path.

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Pavol Rusnak]

On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:
> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
> we need this field.

But the depth of exported public key will be null. It does not make
sense to export xpub for m or m/0' for your particular case.

> I think it should always be present if a chain is
> limited to a certain script type.

I am fine with having the path there all the time.

> There is however the case where even on one chain, script types are
> mixed. In this case the field should be omitted and the wallet needs to
> scan for all (known) types. Afaik Bitcoin Core is taking this path.

Is that really the case? Why come up with a hierarchy and then don't use it?

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

[Thomas Voegtlin]

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.