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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
