📅 Original date posted:2020-10-16
📝 Original message:On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> BIP32 [1] says: "In order to prevent these from depending solely on the key
> itself, we extend both private and public keys first with an extra 256 bits of
> entropy. This extension, called the chain code...".
>
> My argument is that the chain code is not needed.
> To support such claim, I'll show a schematic of BIP32 operations to be compared
> with an alternative proposal and discuss the differences.
>
> I have two main questions:
> - Is this claim false?
> - Has anyone shared this idea before?
Hi Leonardo,
It's been a while but I can comment on the history of how the chaincode ended up being in there.
The most direct reason is that BIP32 was inspired by Alan Reiner's Armory software, which had
a different homomorphic key derivation scheme, but included something called a chaincode to
enable multiple "chains" of keys to be derived from the same keypair. More information about
that scheme is here: https://bitcointalk.org/index.php?topic=205999.msg2155696#msg2155696
BIP32 made two improvements to this:
* Allow efficient random access into the derived keys (Armory's scheme required iterating the
derivation function to get consecutive subkeys - which is probably where the name "chain"
in chaincode comes from)
* Permit hierarchical derivation, by also constructing a sub-"chaincode" along with every subkey.
If I recall correctly, there was at least one argument at the time about whether the chaincode was
necessary at all. My rationale for keeping it was:
* xpubs are not as secret as private keys, but they do demand more protection than just public keys
(for both privacy reasons, and due to the fact that revealing an xpub + child xprv is ReallyBad(tm)).
For that reason, it seems nice that an xpub consists of more than just a public key, as revealing
the public key in it means the protection above remains. I don't think there is anything fundamental
here; just a distinct encoding for xpubs and pubkeys might have accomplished the same, but this
felt safer.
* Repeated hashing "felt" dangerous, as it reduces entropy at every step, so it'd go below 256 bits.
With a chaincode to maintain extra entropy this is prevented. In retrospect, this is a bogus
argument, as it's only a relevant point for information-theoretical security (which means we wouldn't
be able to use ECC in the first place), and even then, it's only a minimal effect.
So in short, from a cryptographic point of view, I think that indeed, the chaincode is not needed. It
probably has some qualitative advantage in practice, but not very much.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201016/ebd8144d/attachment.html>;
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 18:27:20
in reply to nevent1q…lg5s
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 18:27:20Event JSON
{
"id": "c71de4c45aca7b794712b7f061a61764c9460e61f3dc684f8c1dfca10a9dd453",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686162440,
"kind": 1,
"tags": [
[
"e",
"62b0aba983f63dce09e17759a0c7c52dc2a223da106340f0225d104e51842c19",
"",
"root"
],
[
"e",
"9b531151402da423c8aef0a556d221f7f3b465a3118f37c2d0ffc7b75f630d43",
"",
"reply"
],
[
"p",
"2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d"
]
],
"content": "📅 Original date posted:2020-10-16\n📝 Original message:On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi all,\n\u003e\n\u003e BIP32 [1] says: \"In order to prevent these from depending solely on the key\n\u003e itself, we extend both private and public keys first with an extra 256 bits of\n\u003e entropy. This extension, called the chain code...\".\n\u003e\n\u003e My argument is that the chain code is not needed.\n\u003e To support such claim, I'll show a schematic of BIP32 operations to be compared\n\u003e with an alternative proposal and discuss the differences.\n\u003e\n\u003e I have two main questions:\n\u003e - Is this claim false?\n\u003e - Has anyone shared this idea before?\n\nHi Leonardo,\n\nIt's been a while but I can comment on the history of how the chaincode ended up being in there.\n\nThe most direct reason is that BIP32 was inspired by Alan Reiner's Armory software, which had\na different homomorphic key derivation scheme, but included something called a chaincode to\nenable multiple \"chains\" of keys to be derived from the same keypair. More information about\nthat scheme is here: https://bitcointalk.org/index.php?topic=205999.msg2155696#msg2155696\n\nBIP32 made two improvements to this:\n* Allow efficient random access into the derived keys (Armory's scheme required iterating the\nderivation function to get consecutive subkeys - which is probably where the name \"chain\"\nin chaincode comes from)\n* Permit hierarchical derivation, by also constructing a sub-\"chaincode\" along with every subkey.\n\nIf I recall correctly, there was at least one argument at the time about whether the chaincode was\nnecessary at all. My rationale for keeping it was:\n* xpubs are not as secret as private keys, but they do demand more protection than just public keys\n(for both privacy reasons, and due to the fact that revealing an xpub + child xprv is ReallyBad(tm)).\nFor that reason, it seems nice that an xpub consists of more than just a public key, as revealing\nthe public key in it means the protection above remains. I don't think there is anything fundamental\nhere; just a distinct encoding for xpubs and pubkeys might have accomplished the same, but this\nfelt safer.\n* Repeated hashing \"felt\" dangerous, as it reduces entropy at every step, so it'd go below 256 bits.\nWith a chaincode to maintain extra entropy this is prevented. In retrospect, this is a bogus\nargument, as it's only a relevant point for information-theoretical security (which means we wouldn't\nbe able to use ECC in the first place), and even then, it's only a minimal effect.\n\nSo in short, from a cryptographic point of view, I think that indeed, the chaincode is not needed. It\nprobably has some qualitative advantage in practice, but not very much.\n\nCheers,\n\n--\nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201016/ebd8144d/attachment.html\u003e",
"sig": "1ab86d757c694543b14c608db26321f90e843b6776e4f9e4c04a46492a00f09140fd2809d4a7132aebbbc9208c5edab5679a1e8e187492c5486a271815c08ba2"
}