Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bip174: add global xpub field #784

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@achow101
Copy link
Member

commented May 14, 2019

Adds a global type for xpubs as discussed on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016894.html

@achow101

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

@peter-conalgo

This comment has been minimized.

Copy link

commented May 14, 2019

+1 would implement

@stepansnigirev

This comment has been minimized.

Copy link

commented May 14, 2019

Just to clarify

It should be the public key at the highest hardened derivation index

Should means that it's a recommendation and I still can use non-hardened derivation index, right? If so, +1 from my side.

@achow101

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

Should means that it's a recommendation and I still can use non-hardened derivation index, right?

Yes. It is a recommendation, not a requirement.

@matthewleon

This comment has been minimized.

Copy link

commented May 14, 2019

It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.

This is a somewhat confusing sentence. At a minimum, the word highest seems ambiguous. Perhaps an example could also be provided to clarify?

@peter-conalgo

This comment has been minimized.

Copy link

commented May 17, 2019

I think we're going to need a different 'key' for this field. Here are three xpub's with the same fingerprint, and if BIP45 was being used, they would all have the same derivation (m/45'). Without having a repeating key value, there is no way to represent this in the proposed PSBT format.

tpubD8NXmKsmWp3a3HvTG3Pe2mmkmwMfNPvVd4GorFdaQpnwV8v79zEchTuLkt1Ehz7ou5icAFYxDbS7gR592VocShPqNnmwDQcdbcPdDyVhAiG
tpubD8NXmKsmWp3a2S1WnJk9GBXBpJNEWEd5HEQsMtV29Kk4uBzxuH1JGBq8oLAHmmVgZCiXdGANT35niN1ibSZatwQ7zHYsTtWrzjo6aKK11g4
tpubD8NXmKsmWp3a1Hj6i1Be5fVbbRfH4Hg2reAZ9ctaizJFc9ddLG5GSHnS4f3iprEmrbFPWLmgsir2s9CaXQp2fVVMs5zVbJTnhvMxoErXQCW

[Aside: All share F1CFD170. These are constructed by modulating the chain code, but as a 32-bit truncated hash, there will be legitimate fingerprint collisions in real-world examples.]

As for a better key value to use, I think an index (32-bits, ascending) would be enough, or we could use the public key (33 bytes, compressed only).

IMHO, the key derivation path is not useful information since I cannot verify it, but maybe it's useful to detect innocent errors between the global section and paths in the ins/outs.

In conclusion, I propose we switch from using the (extended key fingerprint + key path) to just an (index + key path). Must start at zero, no gaps and so on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.