public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Leonardo Comandini <leonardocomandini@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Is BIP32's chain code needed?
Date: Fri, 16 Oct 2020 21:41:07 +0000	[thread overview]
Message-ID: <xudKQNCJGHcx56H5Aajyo8edv-s5PvGDVDrNR4kdjQXawvewOxb1E5zB-ieHY8T9SUu9FJVa2Ea4_oa4LPbXmzK1C4kOJ8pogqvONDXwg70=@wuille.net> (raw)
In-Reply-To: <CACmzyU-XVNxLQ8o5CQrhmxGocK6yAX1nCFT2WQ-si157y=dfwQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev <bitcoin-dev@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

[-- Attachment #2: Type: text/html, Size: 3680 bytes --]

  parent reply	other threads:[~2020-10-16 21:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29 17:34 Leonardo Comandini
2020-10-05  2:49 ` Lloyd Fournier
2020-10-05 20:34 ` Christopher Allen
2020-10-16 21:41 ` Pieter Wuille [this message]
2020-10-17  9:14   ` Adam Back

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='xudKQNCJGHcx56H5Aajyo8edv-s5PvGDVDrNR4kdjQXawvewOxb1E5zB-ieHY8T9SUu9FJVa2Ea4_oa4LPbXmzK1C4kOJ8pogqvONDXwg70=@wuille.net' \
    --to=bitcoin-dev@wuille$(echo .)net \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=leonardocomandini@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox