1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Return-Path: <adam.back@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 24A6CC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Oct 2020 09:15:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 12E4B2052B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Oct 2020 09:15:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vSvIjCYtWRmi
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Oct 2020 09:15:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com
[209.85.208.51])
by silver.osuosl.org (Postfix) with ESMTPS id 625B420522
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Oct 2020 09:15:15 +0000 (UTC)
Received: by mail-ed1-f51.google.com with SMTP id t21so5176223eds.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Oct 2020 02:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:reply-to:from:date:message-id
:subject:to:cc;
bh=gDmXaq6iimsqjLTfz2dtVaN7Q0isa5rY2NvRCCQYyEs=;
b=rZmWZNGXBFMejCgLsum00HZcibi2BKwf5U5azF5NBSObKhHf+tKVr442uXOCGUvakS
qK+U19drhd/t8/tGcrrOxKq1goFkQCBoomY9CEp412Zkl3tJhOHORT0Mp2C/28wATcIG
Np+BzayUzNMYpx9PV8Q8riuumGBMLTHC4j/GbQfboZ7d42hByBu5C6Uqv6Axpqmb76oW
NbLfqcHgdAzUbgq6l7ye2vdMQM/t1akgOK2ZzQBGAXGvLPx+smLNQCLuuD0H7lklLbYJ
Hbq/0blSlgX/GPE3IeKzu1l4o8LeuPI2SL7BYS9BdORAIKvoOWmJTMzavrNmn5hW5UYS
Nivw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:reply-to
:from:date:message-id:subject:to:cc;
bh=gDmXaq6iimsqjLTfz2dtVaN7Q0isa5rY2NvRCCQYyEs=;
b=n8iTKRdARnjv/JC1lB4YtuwAyioYFxcO/Uxf8tvtBlwQeb9BRRvx6fS1ysfSUKWXDJ
AYG6vgASzotgw9pf6uIdRwOvizTQPjylYoRQxjSSPw6qsnOBrGyEntc+M29S3EpFFdoW
n6cc0QEvSkeH3Mm/ijvTe76RBq7YWrMkxE2KNqzz0Lc7InJQw7PXVvt7dtb++/5oEstn
NHFt99FkX1I3IoxFDW9nuUbXrX7BEbG1Kjh2VUzudsT7e64zVB+/21JD2X5hN1WA5/vA
txj2L4EPx9lKEYy/ZkBI159/S1KJ6LxDF9GaEsI2/PSE0NjuLojmUboTf5v63sxu/gWs
7vgQ==
X-Gm-Message-State: AOAM531JkREavvYEVgz/pCeSi9OS88Dsd0pKFfaGIGtpxktK5i49QUuE
UNzNeRJtUkKawXkxDwQXRRuvLqGtmheENubyl9w=
X-Google-Smtp-Source: ABdhPJxRd8dQ0KaBmR3vOOJHkimcQU6m/yrNBTuI/YJyfUIGsxI9LQZUbvhV3pt02g8SMOhmBS0ugHFrTFvXUK7A3+s=
X-Received: by 2002:a05:6402:744:: with SMTP id
p4mr8242302edy.190.1602926113506;
Sat, 17 Oct 2020 02:15:13 -0700 (PDT)
MIME-Version: 1.0
References: <CACmzyU-XVNxLQ8o5CQrhmxGocK6yAX1nCFT2WQ-si157y=dfwQ@mail.gmail.com>
<xudKQNCJGHcx56H5Aajyo8edv-s5PvGDVDrNR4kdjQXawvewOxb1E5zB-ieHY8T9SUu9FJVa2Ea4_oa4LPbXmzK1C4kOJ8pogqvONDXwg70=@wuille.net>
In-Reply-To: <xudKQNCJGHcx56H5Aajyo8edv-s5PvGDVDrNR4kdjQXawvewOxb1E5zB-ieHY8T9SUu9FJVa2Ea4_oa4LPbXmzK1C4kOJ8pogqvONDXwg70=@wuille.net>
Reply-To: adam@cypherspace.org
From: Adam Back <adam.back@gmail.com>
Date: Sat, 17 Oct 2020 11:14:59 +0200
Message-ID: <CALqxMTG+R=aXwkEGF7eD37qJEgcoOCQmjTBeD+h+n10Hbp3mtQ@mail.gmail.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Is BIP32's chain code needed?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Oct 2020 09:15:17 -0000
Another advantage of random access from BIP 32 vs iterated chain is
that if there is a bit-flip or corruption, you don't destroy access to
all future addresses, but only burn one utxo. Empirically not an
entirely theoretical issue.
I think the only thing i'd care about is bloating up the number of
characters to backup, if the codes are all derived it doesn't matter
too much. I tend to think of 128-bits as enough given that is the
security target of ECDSA, so long as reasonable key-stretching
algorithms are used that don't interact badly with the key use, which
seems a very reasonable assumption for PBKF2 and ECDSA.
Agree the iterated hashing argument does not seem a practical concern
- eg BIP 39 uses PBKDF2 uses 2048 iterated hash invocations. I
suppose it's strictly true that as the hash is deterministic and not a
bijection (not a permutation), there are collisions and if you iterate
enough unreachable states can be eliminated. But because the domain
is so large as to be practically unenumerable it won't creates a brute
force short-cut
Adam
On Sat, 17 Oct 2020 at 01:35, Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
