<div>On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div>Hi all,<br></div><div><div><br></div><div>BIP32 [1] says: "In order to prevent these from depending solely on the key <br></div><div>itself, we extend both private and public keys first with an extra 256 bits of <br></div><div>entropy. This extension, called the chain code...".<br></div><div><br></div><div>My argument is that the chain code is not needed.<br></div><div>To support such claim, I'll show a schematic of BIP32 operations to be compared<br></div><div>with an alternative proposal and discuss the differences.<br></div><div><br></div><div>I have two main questions:<br></div><div>- Is this claim false?<br></div><div>- Has anyone shared this idea before?<br></div></div></div></blockquote><div><br></div><div>Hi Leonardo,<br></div><div><br></div><div>It's been a while but I can comment on the history of how the chaincode ended up being in there.<br></div><div><br></div><div>The most direct reason is that BIP32 was inspired by Alan Reiner's Armory software, which had<br></div><div>a different homomorphic key derivation scheme, but included something called a chaincode to<br></div><div>enable multiple "chains" of keys to be derived from the same keypair. More information about<br></div><div>that scheme is here: <a href="https://bitcointalk.org/index.php?topic=205999.msg2155696#msg2155696">https://bitcointalk.org/index.php?topic=205999.msg2155696#msg2155696</a><br></div><div><br></div><div>BIP32 made two improvements to this:<br></div><div>* Allow efficient random access into the derived keys (Armory's scheme required iterating the<br></div><div>  derivation function to get consecutive subkeys - which is probably where the name "chain"<br></div><div>  in chaincode comes from)<br></div><div>* Permit hierarchical derivation, by also constructing a sub-"chaincode" along with every subkey.<br></div><div><br></div><div>If I recall correctly, there was at least one argument at the time about whether the chaincode was<br></div><div>necessary at all. My rationale for keeping it was:<br></div><div>* xpubs are not as secret as private keys, but they do demand more protection than just public keys<br></div><div>  (for both privacy reasons, and due to the fact that revealing an xpub + child xprv is ReallyBad(tm)).<br></div><div>  For that reason, it seems nice that an xpub consists of more than just a public key, as revealing<br></div><div>  the public key in it means the protection above remains. I don't think there is anything fundamental<br></div><div>  here; just a distinct encoding for xpubs and pubkeys might have accomplished the same, but this<br></div><div>  felt safer.<br></div><div>* Repeated hashing "felt" dangerous, as it reduces entropy at every step, so it'd go below 256 bits.<br></div><div>  With a chaincode to maintain extra entropy this is prevented. In retrospect, this is a bogus<br></div><div>  argument, as it's only a relevant point for information-theoretical security (which means we wouldn't<br></div><div>  be able to use ECC in the first place), and even then, it's only a minimal effect.<br></div><div><br></div><div>So in short, from a cryptographic point of view, I think that indeed, the chaincode is not needed. It<br></div><div>probably has some qualitative advantage in practice, but not very much.<br></div><div><br></div><div>Cheers,<br></div><div><br></div><div>-- <br></div><div>Pieter<br></div><div><br></div><div><br></div>