Pavol Rusnak [ARCHIVE] on Nostr: 📅 Original date posted:2016-04-21 📝 Original message:On 21/04/16 17:28, Eric ...
📅 Original date posted:2016-04-21
📝 Original message:On 21/04/16 17:28, Eric Lombrozo via bitcoin-dev wrote:
> I don't think we've ever had to handle this case.
This is the main problem: we are not sure, because not a lot of software
does this checks. Also even if you do check, it's hard to handle an
exception (you can't always skip - what if the problematic node is m/44'?).
One of the motivations is to fix BIP-32 so it can be used for
non-secp256k1 curves as well. For NIST P-256 curve this chance is 2^-32.
Jochen even managed to find an example[1]:
m/28578'/33941 where m is derived from
"000102030405060708090a0b0c0d0e0f" seed.
[1]
https://github.com/trezor/trezor-crypto/commit/16ff4387ae79429e629a5454708abf7385b3a9a3
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
SatoshiLabs.com
📝 Original message:On 21/04/16 17:28, Eric Lombrozo via bitcoin-dev wrote:
> I don't think we've ever had to handle this case.
This is the main problem: we are not sure, because not a lot of software
does this checks. Also even if you do check, it's hard to handle an
exception (you can't always skip - what if the problematic node is m/44'?).
One of the motivations is to fix BIP-32 so it can be used for
non-secp256k1 curves as well. For NIST P-256 curve this chance is 2^-32.
Jochen even managed to find an example[1]:
m/28578'/33941 where m is derived from
"000102030405060708090a0b0c0d0e0f" seed.
[1]
https://github.com/trezor/trezor-crypto/commit/16ff4387ae79429e629a5454708abf7385b3a9a3
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
SatoshiLabs.com