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

[Pavol Rusnak via bitcoin-dev]

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.

[Thomas Voegtlin via bitcoin-dev]

Post by Pavol Rusnak via bitcoin-dev
The discussion about changing bip32 version bytes for SegWit got me
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

[Pavol Rusnak via bitcoin-dev]

Post by Thomas Voegtlin via bitcoin-dev
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?

[Kabuto Samourai via bitcoin-dev]

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 <

Post by Pavol Rusnak via bitcoin-dev

Post by Thomas Voegtlin via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Andreas Schildbach via bitcoin-dev]

Post by Pavol Rusnak via bitcoin-dev

Post by Thomas Voegtlin via bitcoin-dev
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.

Post by Pavol Rusnak via bitcoin-dev
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.

[Pavol Rusnak via bitcoin-dev]

Post by Andreas Schildbach via bitcoin-dev
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.

Post by Andreas Schildbach via bitcoin-dev
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.

Post by Andreas Schildbach via bitcoin-dev
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?

[Thomas Voegtlin via bitcoin-dev]

Post by Pavol Rusnak via bitcoin-dev

Post by Thomas Voegtlin via bitcoin-dev
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.

[Kabuto Samourai via bitcoin-dev]

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 <

Post by Pavol Rusnak via bitcoin-dev
The discussion about changing bip32 version bytes for SegWit got me
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-Kabuto

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

[Pavol Rusnak via bitcoin-dev]

Post by Kabuto Samourai via bitcoin-dev
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.

Post by Kabuto Samourai via bitcoin-dev
Could you also add some test vectors?

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

Post by Kabuto Samourai via bitcoin-dev
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

[Pavol Rusnak via bitcoin-dev]

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.

[Peter Todd via bitcoin-dev]

Post by Pavol Rusnak via bitcoin-dev

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!

[Jonas Schnelli via bitcoin-dev]

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

Post by Pavol Rusnak via bitcoin-dev
The discussion about changing bip32 version bytes for SegWit got me
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Kabuto Samourai via bitcoin-dev
Thanks for the proposal.
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.

[Pavol Rusnak via bitcoin-dev]

Post by Jonas Schnelli via bitcoin-dev
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.

Post by Jonas Schnelli via bitcoin-dev
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.

Post by Jonas Schnelli via bitcoin-dev
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.