-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
BIP32: Modified test vectors for hardened derivation with leading zeros #1030
Conversation
I think old test vectors should not be deleted. They are needed as regression tests. FYI bitcoinj passes the new test vectors without changes. |
The code in bitcointx correctly handles this, but just to be in-sync with the text of the BIP, use the new test vectors submitted in bitcoin/bips#1030 (when it is merged)
0b967ec
to
b0521f0
Compare
@schildbach |
The code in bitcointx correctly handles this, but just to be in-sync with the text of the BIP, use the new test vectors submitted in bitcoin/bips#1030 (when it is merged)
Thanks for sharing the test fixture! |
So existing Test 3 is for testing if the initial seed -> master generation step works with a 0x00 leading private key part. This makes sense since most implementations perform the HMACs for LGTM |
The code in bitcointx correctly handles this, but just to be in-sync with the text of the BIP, use the new test vectors submitted in bitcoin/bips#1030 (when it is merged)
also yet-to-be-merged test from bitcoin/bips#1030
What exactly is the hold-up here? LGTM! |
… leading zeros 516e46a Additional BIP32 test vector for hardened derivation with leading zeros (Kristaps Kaupe) Pull request description: See [Inconsistent BIP32 Derivations](https://blog.polychainlabs.com/bitcoin,/bip32,/bip39,/kdf/2021/05/17/inconsistent-bip32-derivations.html) and bitcoin/bips#1030. Top commit has no ACKs. Tree-SHA512: 7c0d6f988391297ba83fbebb88f890e88d7458a963e58497714f7385a9982a0c5898d8bbfc3852f51ba3b433d419449bb1e1ca95c2832780628123f66a12e1ad
ACK, verified that it actually exercises derivation from a private key with leading 0 byte. |
ACK b0521f0 |
…ion with leading zeros 91ef834 Additional test vector for hardened derivation with leading zeros (Kristaps Kaupe) Pull request description: See [Inconsistent BIP32 Derivations](https://blog.polychainlabs.com/bitcoin,/bip32,/bip39,/kdf/2021/05/17/inconsistent-bip32-derivations.html) and bitcoin/bips#1030. ACKs for top commit: practicalswift: cr ACK 91ef834 sipa: ACK 91ef834. Verified that it matches the linked BIP32 update, and that it indeed tests derivation from a private key with leading 0 byte. Tree-SHA512: 0a3ae7aed15e4e08e9bec5db8de53c6c03ed3b3632f390394eea422597755173cbd2228ff0cfa57f5aae3df9d4cdf03a8ef4725cc8bce86ab7d9c82ab9d479ad
…derivation with leading zeros 91ef834 Additional test vector for hardened derivation with leading zeros (Kristaps Kaupe) Pull request description: See [Inconsistent BIP32 Derivations](https://blog.polychainlabs.com/bitcoin,/bip32,/bip39,/kdf/2021/05/17/inconsistent-bip32-derivations.html) and bitcoin/bips#1030. ACKs for top commit: practicalswift: cr ACK 91ef834 sipa: ACK 91ef834. Verified that it matches the linked BIP32 update, and that it indeed tests derivation from a private key with leading 0 byte. Tree-SHA512: 0a3ae7aed15e4e08e9bec5db8de53c6c03ed3b3632f390394eea422597755173cbd2228ff0cfa57f5aae3df9d4cdf03a8ef4725cc8bce86ab7d9c82ab9d479ad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK b0521f0
A new test vectors was introduced in bitcoin/bips#1030 because some wallets didn't handle leading zeros correctly in hardened derivation. We already handled that case correctly, but didn't have a test vector for it.
A new test vector was introduced in bitcoin/bips#1030 because some wallets didn't handle leading zeros correctly in hardened derivation. We already handled that case correctly, but didn't have a test vector for it.
We were doing The Right Thing! See bitcoin/bips#1030 Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
ACK b0521f0 - tested in darosior/python-bip32#16 |
A new test vectors was introduced in bitcoin/bips#1030 because some wallets didn't handle leading zeros correctly in hardened derivation. We already handled that case correctly, but didn't have a test vector for it.
A new test vector was introduced in bitcoin/bips#1030 because some wallets didn't handle leading zeros correctly in hardened derivation. We already handled that case correctly, but didn't have a test vector for it.
The code in bitcointx correctly handles this, but just to be in-sync with the text of the BIP, use the new test vectors submitted in bitcoin/bips#1030 (when it is merged)
…derivation with leading zeros 91ef834 Additional test vector for hardened derivation with leading zeros (Kristaps Kaupe) Pull request description: See [Inconsistent BIP32 Derivations](https://blog.polychainlabs.com/bitcoin,/bip32,/bip39,/kdf/2021/05/17/inconsistent-bip32-derivations.html) and bitcoin/bips#1030. ACKs for top commit: practicalswift: cr ACK 91ef834 sipa: ACK 91ef834. Verified that it matches the linked BIP32 update, and that it indeed tests derivation from a private key with leading 0 byte. Tree-SHA512: 0a3ae7aed15e4e08e9bec5db8de53c6c03ed3b3632f390394eea422597755173cbd2228ff0cfa57f5aae3df9d4cdf03a8ef4725cc8bce86ab7d9c82ab9d479ad
…derivation with leading zeros 91ef834 Additional test vector for hardened derivation with leading zeros (Kristaps Kaupe) Pull request description: See [Inconsistent BIP32 Derivations](https://blog.polychainlabs.com/bitcoin,/bip32,/bip39,/kdf/2021/05/17/inconsistent-bip32-derivations.html) and bitcoin/bips#1030. ACKs for top commit: practicalswift: cr ACK 91ef834 sipa: ACK 91ef834. Verified that it matches the linked BIP32 update, and that it indeed tests derivation from a private key with leading 0 byte. Tree-SHA512: 0a3ae7aed15e4e08e9bec5db8de53c6c03ed3b3632f390394eea422597755173cbd2228ff0cfa57f5aae3df9d4cdf03a8ef4725cc8bce86ab7d9c82ab9d479ad
…derivation with leading zeros 91ef834 Additional test vector for hardened derivation with leading zeros (Kristaps Kaupe) Pull request description: See [Inconsistent BIP32 Derivations](https://blog.polychainlabs.com/bitcoin,/bip32,/bip39,/kdf/2021/05/17/inconsistent-bip32-derivations.html) and bitcoin/bips#1030. ACKs for top commit: practicalswift: cr ACK 91ef834 sipa: ACK 91ef834. Verified that it matches the linked BIP32 update, and that it indeed tests derivation from a private key with leading 0 byte. Tree-SHA512: 0a3ae7aed15e4e08e9bec5db8de53c6c03ed3b3632f390394eea422597755173cbd2228ff0cfa57f5aae3df9d4cdf03a8ef4725cc8bce86ab7d9c82ab9d479ad
…derivation with leading zeros 91ef834 Additional test vector for hardened derivation with leading zeros (Kristaps Kaupe) Pull request description: See [Inconsistent BIP32 Derivations](https://blog.polychainlabs.com/bitcoin,/bip32,/bip39,/kdf/2021/05/17/inconsistent-bip32-derivations.html) and bitcoin/bips#1030. ACKs for top commit: practicalswift: cr ACK 91ef834 sipa: ACK 91ef834. Verified that it matches the linked BIP32 update, and that it indeed tests derivation from a private key with leading 0 byte. Tree-SHA512: 0a3ae7aed15e4e08e9bec5db8de53c6c03ed3b3632f390394eea422597755173cbd2228ff0cfa57f5aae3df9d4cdf03a8ef4725cc8bce86ab7d9c82ab9d479ad
As mentioned in bitpay/bitcore-lib#47, iancoleman/bip39#58 and btcsuite/btcutil#172, the private key with leading zeros(i.e. less than 32 bytes) should be padded to 32 bytes when we derive a hardened child private key from a private key.
Unfortunately, the original test vector 3 is not suitable for this case since both keys are 32 bytes.
In the new test vectors, the key m/0H is 31 bytes.
btcsuite/btcutil just fix the bug. See btcsuite/btcutil#182.