-
Notifications
You must be signed in to change notification settings - Fork 35.6k
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
BIP-178: Extend WIF format with key type #12869
Conversation
7c7317f
to
d3ac507
Compare
😯 |
TIL Ethereum has Segwit. |
Oops.. fixed. |
d3ac507
to
1514770
Compare
Ideally we would first draft/spec the WIF "standard" in the form of a BIP. General Concpet ACK |
I did. The I posted it in the ML but as a reply to the existing thread, here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015870.html (* It is not actually a PR yet.) |
af65199
to
ae6095f
Compare
@kallewoof This link https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki is broken. I can't find this BIP-178 proposal anywhere else than in the mailing list. |
@Janaka-Steph I updated the link: https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-0178.mediawiki The PR is here: bitcoin/bips#673 |
5777230
to
b4287f5
Compare
Needs rebase due to merge of #12924 |
b4287f5
to
0aa2d2f
Compare
0aa2d2f
to
f3b064c
Compare
Rebased. |
It feels wrong to store the address type in |
@sipa The |
@kallewoof The compressed flag affects the public key, not the address. Different private keys (including compressed flag) correspond to different public keys (when looking at the bytes, which is what matters to us). Where should it go? Right now, nowhere - we can't use it, as the I understand it seems easiest to store it in |
That makes sense. Maybe I should just close this PR, then. I could always rework it to split out the |
BIP pull request: bitcoin/bips#673
This PR does not change the behavior. It only adds underlying support for formats beyond 'compressed pubkey' and 'uncompressed pubkey'. It partially implements BIP-178.
The key types are based on the key types in
EthereumElectrum 3.0: https://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108The legacy types
KEY_P2PKH_{UN}COMPRESSED
map to the current WIF format. If used/seen, they indicate that the corresponding public key type is unknown, and when imported, they will simply iterate over all types and watch all of them (P2PKH, P2SH-P2WPKH, P2WPKH (bech32), and so on). (Current behavior.)When one of the other types is used, the current code will behave exactly the same as above. In a future PR, the code will be changed to only import the corresponding type when importing a private key.
This is related to #12705, see in particular #12705 (comment).