Correct BIP-32 derivation issue #182
Conversation
|
Well done! |
Roasbeef
left a comment
Roasbeef
left a comment
There was a problem hiding this comment.
Thanks for this set of changes! Picking this over the older one assuming that we can get this one in sooner. Also the commit message should have the package/folder prefix as specified in the contribution guidelines.
| copy(data[1:], k.key) | ||
| // Additionally, right align it if it's shorter than 32 bytes. | ||
| offset := 33 - len(k.key) | ||
| copy(data[offset:], k.key) |
There was a problem hiding this comment.
Rather than silently changing the behavior of this method, which can cause issues for any wallet that relies on this quirk as is (say when rescanning), I think we should instead break this method, and force callers to choose one or the other.
In other words: add a new variable to this method, and/or a helper func that assumes a new default value for this variable.
There was a problem hiding this comment.
renamed ChildNonStandard to DeriveNonStandard and Child to Derive. added a usage note
devrandom
force-pushed
the
bip32-zeros
branch
from
b10d526 to
dde9e31
Compare
|
cc @guggero |
4 participants
Fixes issue #172.
This issue affects 1 in 256 hardened key derivations. For standard BIP-44 accounts, this affects the coin and account derivations, so 1 in 128 accounts will not be compatible with other BIP-44 implementations.
The intention is that wallet implementations using btcutil can use the
IsAffectedByIssue172call to check if they are affected, and potentially migrate (or ask the user to create a new wallet).