From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 24A6CC0051 for ; 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 ; 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 ; 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 ; Sat, 17 Oct 2020 09:15:15 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id t21so5176223eds.6 for ; 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: In-Reply-To: Reply-To: adam@cypherspace.org From: Adam Back Date: Sat, 17 Oct 2020 11:14:59 +0200 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > > On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev 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