From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2F37EC0051 for ; Mon, 5 Oct 2020 20:35:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 1030A866E5 for ; Mon, 5 Oct 2020 20:35:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKoNgfyV82cS for ; Mon, 5 Oct 2020 20:35:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) by whitealder.osuosl.org (Postfix) with ESMTPS id AF317866E2 for ; Mon, 5 Oct 2020 20:35:25 +0000 (UTC) Received: by mail-vs1-f42.google.com with SMTP id w25so4958927vsk.9 for ; Mon, 05 Oct 2020 13:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifewithalacrity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=b2D8fJWAconxLQ7dlbh365IZ5e2VDJN35dBCLUFM6Zs=; b=vwAFJWeXvII9BopVJS6wNGKQUJRYfC1tSd7iV45jlyOABwCaaxLvdhSMEl7ak58/am BlSyLIHjhN3yk43T64GF3dFgS6okM4MCB0odiZDiZ/LmQ1izk54dF0dEQHnaFp2d3nhZ rYLLoJB/yNfJH82T50tu5HBbiqe+OPwkhlrNNH0j9mTQzaVazOG7zHGiKv8hu6vRBGkX 5PJQBzHJvqavHoyeWgMURMTWMtDt0KJdY1FNzCi9eRAjvXlyfaKXozC7Vb037LKEO+d0 oMx0nZI44qboIsyegm7dzGwzifjfKJNGtSYEpfYxN6UFO1oOkTDY4Up6VgsddZtN6awH ClGQ== 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:from:date :message-id:subject:to; bh=b2D8fJWAconxLQ7dlbh365IZ5e2VDJN35dBCLUFM6Zs=; b=ODQhe7dJd9BoLMw86QoYE3MLuWlMIPmSsVwWn/W4ffo3e5nkmpQLClfStpph84vaPO 1H8WzWXE3WW5yBf5Fm8m1SrfLVncIoqT3dPUbH2uAA6BnWTKpveyis1ayzeDCi5uLjrf NabXbkQQ9BMsqriwpTKaC+CV4SCE4rfKZQB2FVtbPm9QxuvvJ5ep9wRQ8pg/3jsWvQgY OZNFE1+34gRLwXI0vn509AzfAF65gZlEImbls88a99wzCjIgj4RVIakKbrwUk9Lr7CXC QyaZuGRq9X9vZ6WbzZcCjfy3YvqIh+Yz2zVpP1OR/rMgwCQ6B3XCzXtUTOrNODegoE5u c8/g== X-Gm-Message-State: AOAM530H9BSq3Gr9AOoG5IbSFkd+8C1rOcN8VRGITpGvSvt9PuRLCnsr 8eTYc2Efa+w7TLNvurOWYZXG4Dmw57GghiC8i/A= X-Google-Smtp-Source: ABdhPJwhzsDPaMQVR2NfL0cB3WeVwNbj8WEd/AERy1QtMjjOOcV+Rc+esBEATpnFMxd+6iu95TfBBJeSeeDLk8kwkIU= X-Received: by 2002:a67:cb02:: with SMTP id b2mr1446462vsl.32.1601930124440; Mon, 05 Oct 2020 13:35:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Allen Date: Mon, 5 Oct 2020 13:34:48 -0700 Message-ID: To: Leonardo Comandini , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000005bcc805b0f26c28" X-Mailman-Approved-At: Mon, 05 Oct 2020 20:42:48 +0000 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: Mon, 05 Oct 2020 20:35:27 -0000 --00000000000005bcc805b0f26c28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Leondardo, There are a lot of sub-topics related to your questions that deserve at least some response. I was not involved deeply in bitcoin when BIPs 32/38/39/44/45 emerged, but they were not without some strong differences of opinion and controversy, some of which are reflected in challenges today. Part of the problem is that bitcoin core itself didn't adopt these for a very long time after the various wallet companies had them broadly deployed, so I don't believe that these BIPs have quite the rigor that other BIPs have. Plus some entire sub-topics are missing like a proposed BIP 48 that describes multisig paths for hardware keys. I encourage you to look back both on the PRs for those BIPs, and also archives of this list. Unfortunately, I don't have a curated list of the "best" of these =E2=80=94 maybe a project for a future Blockchain Commons i= ntern. That being said, one particular focus in your question was on how to you turn a master seed into the master key (m/0). Part of the conflict at the time was a number of vendors wanted to avoid the 256 bits of entropy and felt 128 bits were good enough. A compromise was born of that, that even today not all agree with. However, the proposed scheme was "good enough". Today, I feel that how a master seed (entropy that has been turned into a 128 or 256 bit seed and that which is stored in hardware on a ledger/trezor) is turned into the 512 byte master key for m/0 really needs to be preserved, unless someone finds something cryptographically unsafe about it. Why? Interoperability and avoiding vendor lock-in. An example of this is the recent proposal from Satoshi Labs for SLIP-39. We implemented it, but discovered that in practice the same seed restored through BIP39 recovery would result in a different master key than SLIP39 recovery. This is because the Trezor team is one of the parties that were unhappy with the compromise back in the BIP32 days, and thus they've decided that as long as they are replacing BIP39 they would "fix" the method of creation of the master seed. Satoshi Labs has some rationale for these changes, but we (Blockchain Commons and a small community of airgapped wallet developers), felt that the interoperability and lock-in risks were too high. Once you used SLIP39 to create accounts, you must stick with SLIP39. This means you can only restore seeds to wallets that support SLIP39, and most have chosen not to. So we worked on instead a very closely related specification called SSKR that also does Shamir, but uses the same seed->master key technique that BIP32 does. This means that you can restore your SSRK shards back to a seed, then move them to another device that only supports BIP39. This prevents lock-in into a singular or small subset of wallet vendors. Our current research spec is https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-0= 11-sskr.md and reference code for sskr is at https://github.com/BlockchainCommons/bc-seedtool-cli and we hope to offer it as a BIP in future months. There is a small GitHub community discussing this and other emerging airgapped and multisig standards at https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions There is a similar problem with seed mnemonics Lightning Labs implementations, which needed to offer metadata in addition to the seed. This means their mnemonics are also incompatible and also have potential lock-in and interoperability issues. You can't use their seeds with C-Lightining. So we are puzzling through how to meet their needs for metadata (and other parties in the multsig ecosystem were seed storage is not enough and some metadata is needed), yet maximize round-trip interoperability with multiple wallet vendors, and tools for conversion to legacy formats like our seedtool. So though at first glance your math seems correct and there are other, potentially better ways to derive in a hierarchical fashion additional keys, I'd be worried that it would suffer the interoperability and potential lock-in that we are seeing with SLIP-39 and LND. =E2=80=94 Christopher Allen --00000000000005bcc805b0f26c28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Leondardo,

There are a lot of sub-topic= s related to your questions that deserve at least some response.

I was not involved deeply in bitcoin when BIPs 32/38/39/44/45 emer= ged, but they were not without some strong differences of opinion and contr= oversy, some of which are reflected in challenges today. Part of the proble= m is that bitcoin core itself didn't adopt these for a very long time a= fter the various wallet companies had them broadly deployed, so I don't= believe that these BIPs have quite the rigor that other BIPs have. Plus so= me entire sub-topics are missing like a proposed BIP 48 that describes mult= isig paths for hardware keys.

I encourage you to l= ook back both on the PRs for those BIPs, and also archives of this list. Un= fortunately, I don't have a curated list of the "best" of the= se =E2=80=94 maybe a project for a future Blockchain Commons intern.
<= /div>

That being said, one particular focus in your ques= tion was on how to you turn a master seed into the master key (m/0). Part o= f the conflict at the time was a number of vendors wanted to avoid the 256 = bits of entropy and felt 128 bits were good enough.=C2=A0 A compromise was = born of that, that even today not all agree with. However, the proposed sch= eme was "good enough".

Today, I feel tha= t how a master seed (entropy that has been turned into a 128 or 256 bit see= d and that which is stored in hardware on a ledger/trezor) is turned into t= he 512 byte master key for m/0 really needs to be preserved, unless someone= finds something cryptographically unsafe about it. Why? Interoperability a= nd avoiding vendor lock-in.

An example of this is = the recent proposal from Satoshi Labs for SLIP-39. We implemented it, but d= iscovered that in practice the same seed restored through BIP39 recovery wo= uld result in a different master key than SLIP39 recovery. This is because = the Trezor team is one of the parties that were unhappy with the compromise= back in the BIP32 days, and thus they've decided that as long as they = are replacing BIP39 they would "fix" the method of creation of th= e master seed.

Satoshi Labs=C2=A0has some rational= e for these changes, but we (Blockchain Commons and a small community of ai= rgapped=C2=A0wallet developers), felt that the interoperability and lock-in= risks were too high. Once you used SLIP39 to create accounts, you must sti= ck with SLIP39. This means you can only restore seeds to wallets that suppo= rt SLIP39, and most have chosen not to.

So we work= ed on instead a very closely related specification called SSKR that also do= es Shamir, but uses the same seed->master key technique that BIP32 does.= This means that you can restore your SSRK shards back to a seed, then move= them to another device that only supports BIP39. This prevents lock-in int= o a singular or small subset of wallet vendors. Our current research spec i= s https://github.com/BlockchainCommons/Research/blob= /master/papers/bcr-2020-011-sskr.md and reference code for sskr is at= =C2=A0http= s://github.com/BlockchainCommons/bc-seedtool-cli and we hope to offer i= t as a BIP in future months. There is a small GitHub community discussing t= his and other emerging airgapped=C2=A0and multisig standards at=C2=A0https://github.com/BlockchainCommons/Airgapped-Wallet-Community/disc= ussions

There is a similar problem with seed m= nemonics Lightning Labs implementations, which needed to offer metadata in = addition to the seed. This means their mnemonics are also incompatible and = also have potential lock-in and interoperability issues. You can't use = their seeds with C-Lightining. So we are puzzling through how to meet their= needs for metadata (and other parties in the multsig=C2=A0ecosystem were s= eed storage is not enough and some metadata is needed), yet maximize round-= trip interoperability with multiple wallet vendors, and tools for conversio= n to legacy formats like our seedtool.

So though a= t first glance your math seems correct and there are other, potentially bet= ter ways to derive in a hierarchical fashion additional keys, I'd be wo= rried that it would suffer the interoperability and potential lock-in that = we are seeing with SLIP-39 and LND.

=E2=80=94 Chri= stopher Allen



--00000000000005bcc805b0f26c28--