Christopher Allen [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-05 📝 Original message:Leondardo, There are a lot ...
📅 Original date posted:2020-10-05
📝 Original message: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 — maybe a project for a future Blockchain Commons intern.
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-011-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.
— Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201005/8d92b63e/attachment.html>;
📝 Original message: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 — maybe a project for a future Blockchain Commons intern.
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-011-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.
— Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201005/8d92b63e/attachment.html>;