Published on: 2020-10-17T09:14:59+00:00
In a discussion on the bitcoin-dev mailing list, Leonardo Comandini questions the necessity of the chain code in BIP32. He argues that the additional entropy provided by the chain code is not needed and intends to demonstrate this through a schematic of BIP32 operations. Pieter Wuille, in response, provides historical context on how the chain code ended up being included in BIP32. He explains that BIP32 was inspired by Alan Reiner's Armory software, which had a different key derivation scheme that included a chain code. The chain code allowed for the derivation of multiple "chains" of keys from the same key pair. BIP32 improved upon this by enabling random access into the derived keys and hierarchical derivation with a sub-"chain code" for every subkey.Wuille defends the inclusion of the chain code in BIP32 by stating that xpubs require more protection than public keys alone and that the chain code adds an extra layer of security. Additionally, using a chain code prevents entropy reduction through repeated hashing. However, he acknowledges that from a cryptographic standpoint, the chain code is not necessary and only has practical advantages.The discussion also touches on interoperability and avoiding vendor lock-in. While compromises have been made in the past regarding the amount of entropy used, recent proposals such as SLIP-39 and Lightning Labs' seed mnemonics have raised concerns about interoperability and lock-in issues. The Blockchain Commons and a community of airgapped wallet developers have developed a specification called SSKR, which uses the same seed-to-master key technique as BIP32 to address these concerns.Leonardo Comandini further presents his alternative proposal for key derivation without the chain code. He provides a schematic of BIP32 operations and highlights the advantages of his proposed scheme, including shorter backups for keys and user-friendly backup for child keys. The proposed scheme also allows for mnemonics for subaccount keys. Comandini references various hash functions and provides links to BIP32, BIP39, and a pay-to-contract scheme for more information.Another contributor in the discussion acknowledges that there is no fundamental flaw with Comandini's proposal but admits they haven't spent much time developing wallets.The author of another post argues that the chain code in BIP32 is not necessary and provides a schematic of BIP32 operations to compare with an alternative proposal. The post introduces private and public child derivation formulae, as well as the corresponding chain codes. The post then presents an alternative proposal for derivation without the chain code, using a strong hash function 'h' to convert its output to an integer. This alternative proposal claims to have the same properties as BIP32 and allows for mnemonics for subaccount keys. References [1]-[3] are provided for further information.
Updated on: 2023-08-02T02:44:44.304146+00:00