Why does BIP44 use non-hardened paths at all?
Why does BIP44 use non-hardened paths at all?


Imagine you have a website where you want to sell things. You need the website to be able to generate addresses, but you don't want it to be able to spend from them.

Well, you can give the website an account-level extended public key, and it can generate the non-hardened addresses you need from that. You wouldn't be able to create hardened addresses; you'd need the account private key to make new hardened addresses.

// you now know all my addresses I could derive from hardened. Do you know any
// private keys except for the one I explicitly shared a line before?


No. I know a private key, but I can't work out the parent key or any siblings.

// in difference to the hardened case, you would now learn about nonHardened but
// also (once again) about hardened? What could you actually learn? 


Even though this key isn't hardened, I don't know the chain code of the parent key, so I can't compromise sibling keys or even associate that key with any of its siblings.

// would this line leak any information that wasn't already leaked in the last
// block?


Nope. However, if you also exposed

wallet.derive("m").xpubkey


then I'd have enough information to compromise your wallet.