MIME-Version: 1.0
References: <CACmzyU-XVNxLQ8o5CQrhmxGocK6yAX1nCFT2WQ-si157y=dfwQ@mail.gmail.com>
In-Reply-To: <CACmzyU-XVNxLQ8o5CQrhmxGocK6yAX1nCFT2WQ-si157y=dfwQ@mail.gmail.com>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Mon, 5 Oct 2020 13:34:48 -0700
Message-ID: <CACrqygDrmS5gQ1op7C6h-1KhuC1pFhVBMLEmfO=N1_oLih_g6w@mail.gmail.com>
To: Leonardo Comandini <leonardocomandini@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000005bcc805b0f26c28"
Subject: Re: [bitcoin-dev] Is BIP32's chain code needed?
Precedence: list

--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

<div dir=3D"ltr">Leondardo,<div><br></div><div>There are a lot of sub-topic=
s related to your questions that deserve at least some response.<div><br></=
div><div>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&#39;t adopt these for a very long time a=
fter the various wallet companies had them broadly deployed, so I don&#39;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.</div><div><br></div><div>I encourage you to l=
ook back both on the PRs for those BIPs, and also archives of this list. Un=
fortunately, I don&#39;t have a curated list of the &quot;best&quot; of the=
se =E2=80=94 maybe a project for a future Blockchain Commons intern.</div><=
/div><div><br></div><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 &quot;good enough&quot;.</div><div><br></div><div>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.</div><div><br></div><div>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&#39;ve decided that as long as they =
are replacing BIP39 they would &quot;fix&quot; the method of creation of th=
e master seed.</div><div><br></div><div>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.</div><div><br></div><div>So we work=
ed on instead a very closely related specification called SSKR that also do=
es Shamir, but uses the same seed-&gt;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 <a href=3D"https://github.com/BlockchainCommons/Research/blob/master/pape=
rs/bcr-2020-011-sskr.md">https://github.com/BlockchainCommons/Research/blob=
/master/papers/bcr-2020-011-sskr.md</a> and reference code for sskr is at=
=C2=A0<a href=3D"https://github.com/BlockchainCommons/bc-seedtool-cli">http=
s://github.com/BlockchainCommons/bc-seedtool-cli</a> 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=A0<a hre=
f=3D"https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discus=
sions">https://github.com/BlockchainCommons/Airgapped-Wallet-Community/disc=
ussions</a></div><div><br></div><div>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&#39;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.</div><div><br></div><div>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&#39;d be wo=
rried that it would suffer the interoperability and potential lock-in that =
we are seeing with SLIP-39 and LND.</div><div><br></div><div>=E2=80=94 Chri=
stopher Allen</div><div><br></div><div><br></div><div><br></div></div>

--00000000000005bcc805b0f26c28--