[bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Ethan Kosakovsky]

I would like to present a proposal for discussion and peer review. It aims to solve the problem of "too many seeds and too many backups" due to the many reasons stipulated in the proposal text.

https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-from-bip32.mediawiki

<pre>
  BIP:
  Title: Deterministic Entropy From BIP32 Keychains
  Author: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Proposed
  Type: Standards Track
  Created: 2020-03-20
  License: BSD-2-Clause
           OPL
</pre>

==Abstract==

This proposal provides a way to derive entropy from a HD keychain path in order to deterministically derive the initial entropy used to create keychain mnemonics and seeds.

==Motivation==

BIP32 uses some initial entropy as a seed to deterministically derive a BIP32 root for hierarchical deterministic keychains. BIP39 introduced a method of encoding initial entropy into a mnemonic phrase which is used as input to a one way hash function in order to deterministically derive a BIP32 seed. The motivation behind mnemonic phrases was to make it easier for humans to backup and store offline. There are also other variations of this theme.

The initial motivation of BIP32 was to make handling of large numbers of private keys easier to manage and backup, since you only need one BIP32 seed to cover all possible keys in the keychain. In practice however, due to various wallet implementations and security models, the average user may be faced with the need to handle an ever growing number of seeds/mnemonics. This is due to incompatible wallet standards, hardware wallets (HWW), seed formats and standards, as well as, the need to used a mix of hot and cold wallets depending on the application and environment.

Examples would span wallets on mobile phones, online servers running protocols like Join Market or Lightning, and the difference between Electrum and BIP39 mnemonic seed formats. The reference implementation of Bitcoin Core uses BIP32, while other cryptocurrencies like Monero use different mnemonic encoding schemes.

We must also consider the different variety of physical backups including paper, metal and other physical storage devices, as well as the potentially splitting backups across different geographical locations. This complexity may result in less care being taken with subsequently generated seeds for new wallets need to be stored and it ultimately results in less security. In reality, the idea of having "one seed for all" has proven to be more difficult in practice than originally thought.

Since all these derivation schemes are deterministic based on some initial entropy, this proposal aims to solve the above problems by detailing a way to deterministically derive the initial entropy used for new root keychains using a single BIP32 style "master root key". This will allow one root key or mnemonic to derive any variety of different root keychains in whatever format is required (like BIP32 and BIP39 etc).

==Specification==

Input starts with a BIP32 seed. Derivation scheme uses the format `m/83696968'/type'/index'` where `type` is the final seed type, and `index` in the key index of the hardened child private key.

| type | bits| output                    |
|------|-----|---------------------------|
|   0  | 128 | 12 word BIP39 mnemonic    |
|   1  | 256 | 24 word BIP39 mnemonic    |
|   2  | 128 | 12 word Electrum mnemonic |
|   3  | 256 | 24 word Electrum mnemonic |
|   4  | 256 | WIF for Bitcoin Core      |
|   5  | 256 | 25 word Monero mnemonic   |

Entropy is calculated from the HMAC-SHA512(key=k, msg='bip-entropy-from-bip32') of the derived 32 byte private key (k). Entropy is taken from the result according to the number of bits required. This entropy can then be used as input to derive a mnemonic, wallet etc according to the `type` specified.

==Compatibility==

In order to maintain the widest compatibility, the input to this function is a BIP32 seed, which may or may not have been derived from a BIP39 like mnemonic scheme. This maintains the original motivation that one backup can store any and all child derivation schemes depending on the user's preference or hardware signing devices. For example, devices that store the HD seed as a BIP39 mnemonic, Electrum seed, or BIP32 root key would all be able to implement this standard.

==Discussion==

This proposal could be split into multiple discrete BIPs in the same way that BIP32 described the derivation mechanics, BIP39 the input encoding with mnemonics, and the derivation paths like BIP44, BIP49 and BIP84. This has been avoided to reduce complexity. The resulting private key processed with HMAC-SHA512 and truncated as necessary. HMAC-SHA512 was chosen because it may have better compatibility in embedded devices as it's already required in devices supporting BIP32.

==Test Vectors==

===Test case 1===

MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind employ giant era attitude exit final oval one finger decorate pair useless super method float toddler dance
MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfGJNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
PATH: m/83696968'/0'/0'
BITS REQUIRED: 128

DERIVED CHILD WIF=L3cefeCHyo8jczVjckMxaiPBaPUunc3D8CsjRxYbYp3FhasGpsV3
DERIVED CHILD k=bed343b04ba0216d9eeebff0366b61c4179d90d44b61c716ef6d568836ba4d23
CHILD ENTROPY=6458698fae3578b48a64124ea3514e12
CONVERT ENTROPY TO WIF=KwDiBf89QgGbjEhKnhXJuH7T2Vv72UKQA8KRkmNwVFS2znAS5xb9
CHILD BIP39 MNEMONIC=gold select glue fragile fiscal fog civil liquid exchange box fatal caught
CHILD BIP39 SEED=2a2720e5590d4ec3140e51ba1b0b0a5183222c1668977c8a57572b0ea55d238cd8e899b3b1870e48894ca837e41e5d0db07554715efb21556fdde27f9f7ba153
CHILD BIP32 ROOT KEY=xprv9s21ZrQH143K2ZH5qacptquLGvcYpHSNeyFVCU8Ur4u9kocajbBgcaCbHkGbwDsBR661H29F54j5mz14kwXbY9PZKdNRdjgRcGfshBK9XXb


===Test case 2===

MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind employ giant era attitude exit final oval one finger decorate pair useless super method float toddler dance
MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfGJNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
PATH: m/83696968'/1'/0'
BITS REQUIRED: 256

DERIVED CHILD WIF=L1zCbtnDWUN4vJA3De4sxmJnoRim57CQUuBb4KBoRNs2EMEq2Brg
DERIVED CHILD k=8e3ca6054a6303f4a6a1bcbda6134c9802f4f0a0d76b0ee6b69b06b1e80b2192
CHILD ENTROPY=ec4e2f7e2c3fca9a34fa29747bf8ba0ab7f05136f37e134e2457e9e53639670b
CONVERT ENTROPY TO WIF=L594JSCygt2wBaB9mCpXjiLkkxkEojpBdNXG8UrrdLd2LvPBRMUs
CHILD BIP39 MNEMONIC=unable imitate test flash witness escape stadium early inner thank company betray lecture chuckle swift hurt battle illness bicycle stable fat bronze order high
CHILD BIP39 SEED=73509b0e847ee66bddeb098a55063d73e8c6dd5f1c1db6969c668bb54c19bde6eae8acc29a81118d1d9719fa1bc620fee7edd7c15a17bcaf70b0fdfc0c0c3803
CHILD BIP32 ROOT KEY=xprv9s21ZrQH143K4PfLyyjYLVmKbnUTNFK6Y7jPKWfRZB3iSw1Gy9qowEzkYHfetVabfmjHEEPrcTJbh7chae33Sm9uAjuXzhSL6Li8dcwM9Bm


===Test case 3===

MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind employ giant era attitude exit final oval one finger decorate pair useless super method float toddler dance
MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfGJNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
PATH: m/83696968'/4'/0'
BITS REQUIRED: 256

DERIVED CHILD WIF=KwdD5PYnCU3xQDfFJ6XBf6UDaLrTUxrKmBpdjRuuavWyqAQtpaA2
DERIVED CHILD k=0c169ce2c17bea08512a7519769e365242a1562bd63c4c903daef516000efbf2
CHILD ENTROPY=25573247f8a76799f7abc086b9286b5a7ccb03cb8d3550f48ac1e71d90832974
CONVERT ENTROPY TO WIF=KxUJ8VzMk7uWDEcwYjLRzRMGE6sSpwCfQxkE9GEwAvXhFSDNba9G
CHILD BIP39 MNEMONIC=census ridge music vanish island smooth team job mammal sing bracket reject smile limit comfort pluck extend picture race soda suit dose place obtain
CHILD BIP39 SEED=4e5c82be6455ecf0884d9475435e29a9afb9acf70b07296d7e5039c866e4d54647706918b9d14909dfbd7071a4b7aee8a4ad0ac2bf48f0a09a8899dd28564418
CHILD BIP32 ROOT KEY=xprv9s21ZrQH143K2kekJsK9V6t4ZKwHkY1Q3umxuaAhdZKGxCMpHiddLdYUQBoynszpwnk5upoC788LiT5MZ5q1vUABXG7AMyZK5UjD9iyL7Am

==References==

BIP32, BIP39

==Copyright==

This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Pavol Rusnak]

On 20/03/2020 16:44, Ethan Kosakovsky via bitcoin-dev wrote:
> I would like to present a proposal for discussion and peer review

I read your proposal twice and I still don't know what kind of problem
are you trying to solve.

This should be obvious from the "Abstract" and it's bad if it's not.




-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Ethan Kosakovsky]

Pavol,

Yes thank you. I find abstracts hard, I will try again.

Currently I need a separate BIP30 for many of my wallets. I cant have one master seed for all my wallets because some are less safe than others and storing the master in each environment will increase the chance it could be compromised (e.g. hot environments). I cant export a hardened xprv from my main BIP32 keychain and import it to my JM/Android wallet because they dont support it. There's also a usability issue there since xprvs are not easy to type.

e.g.
1. Join Market server (online)
2. Lightning node (online)
3. Trezor (offline)
4. Smartphone wallet with coffee money (online) (and no HWW support)
5. Bitcoin Core (doesn't use BIP39 at all)

I cannot use the same BIP39 seed across all these services. 1,2,4,5 are effectively hot wallets.

The problem is BIP39. BIP32 is fine but the backup process is not human friendly. It would have been better to simply serialize 128 or 256 bits of entropy into words like BIP39 does and be done with it. After that, it's all deterministic anyway. Instead BIP39 tries to ensure pseudorandom entropy by hash-stretching the initial entropy.

We can already export keychains from BIP32, as xprvs, but there is also no easy way to make as a human readable/typeable like BIP39 mnemonics. Most wallets don't allow you to import an xprv anyway, but again, good luck typing it.

What we are left with is an ecosystem that widely implements BIP39, so practically speaking if I want to use multiple wallets and cannot share an existing seed with that device, I need separate 12 or 24 word mnemonics. That's 5 times the complexity to store than one (in my case). I need a new cryptosteel. If I have two different geological locations for backup, it's hard to add more, since I need to travel. The whole point of BIP32 was one master key would rule them all - set up once, back up once and it's done. BIP39 was simply to make it human friendly to write down the seed on paper.

The easy solution as I see it is have one BIP39 mnemonic as my "master root key". From there it makes a BIP32 keychain and I can deterministically create child BIP39 seeds by taking a hardened path, using the private key as entropy ENT to create a new BIP39 mnemonic. If I do it this way I can have one initial backup, and if I need more wallets with a different seed, I can do it without worrying about backups. I'm future proof this way.

Ethan


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 20, 2020 5:29 PM, Pavol Rusnak <stick@satoshilabs.com> wrote:

> On 20/03/2020 16:44, Ethan Kosakovsky via bitcoin-dev wrote:
>
> > I would like to present a proposal for discussion and peer review
>
> I read your proposal twice and I still don't know what kind of problem
> are you trying to solve.
>
> This should be obvious from the "Abstract" and it's bad if it's not.
>
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Ethan Kosakovsky]

I think my proposal can be summarized simply:

1. get a child private key, hmac it and get entropy bits.
2. Use that entropy to feed BIP39 to make a new mnemonic seed

Bitcoin Core hdseed is a private key, so we can also do the same steps here

1. get a child private key, hmac it and get entropy bits.
2. Use that entropy to create a WIF to become the key for hdseed in Bitcoin Core.

I standardize this by using paths (like BIP44/49)

m/SEED'/BIP39'/index'
m/SEED'/CORE'/index'

index allows me to generate multiple childs for that type.

Ethen

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 20, 2020 6:34 PM, Ethan Kosakovsky <ethankosakovsky@protonmail.com> wrote:

> Pavol,
>
> Yes thank you. I find abstracts hard, I will try again.
>
> Currently I need a separate BIP30 for many of my wallets. I cant have one master seed for all my wallets because some are less safe than others and storing the master in each environment will increase the chance it could be compromised (e.g. hot environments). I cant export a hardened xprv from my main BIP32 keychain and import it to my JM/Android wallet because they dont support it. There's also a usability issue there since xprvs are not easy to type.
>
> e.g.
>
> 1.  Join Market server (online)
> 2.  Lightning node (online)
> 3.  Trezor (offline)
> 4.  Smartphone wallet with coffee money (online) (and no HWW support)
> 5.  Bitcoin Core (doesn't use BIP39 at all)
>
>     I cannot use the same BIP39 seed across all these services. 1,2,4,5 are effectively hot wallets.
>
>     The problem is BIP39. BIP32 is fine but the backup process is not human friendly. It would have been better to simply serialize 128 or 256 bits of entropy into words like BIP39 does and be done with it. After that, it's all deterministic anyway. Instead BIP39 tries to ensure pseudorandom entropy by hash-stretching the initial entropy.
>
>     We can already export keychains from BIP32, as xprvs, but there is also no easy way to make as a human readable/typeable like BIP39 mnemonics. Most wallets don't allow you to import an xprv anyway, but again, good luck typing it.
>
>     What we are left with is an ecosystem that widely implements BIP39, so practically speaking if I want to use multiple wallets and cannot share an existing seed with that device, I need separate 12 or 24 word mnemonics. That's 5 times the complexity to store than one (in my case). I need a new cryptosteel. If I have two different geological locations for backup, it's hard to add more, since I need to travel. The whole point of BIP32 was one master key would rule them all - set up once, back up once and it's done. BIP39 was simply to make it human friendly to write down the seed on paper.
>
>     The easy solution as I see it is have one BIP39 mnemonic as my "master root key". From there it makes a BIP32 keychain and I can deterministically create child BIP39 seeds by taking a hardened path, using the private key as entropy ENT to create a new BIP39 mnemonic. If I do it this way I can have one initial backup, and if I need more wallets with a different seed, I can do it without worrying about backups. I'm future proof this way.
>
>     Ethan
>
>     ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>     On Friday, March 20, 2020 5:29 PM, Pavol Rusnak stick@satoshilabs.com wrote:
>
>
> > On 20/03/2020 16:44, Ethan Kosakovsky via bitcoin-dev wrote:
> >
> > > I would like to present a proposal for discussion and peer review
> >
> > I read your proposal twice and I still don't know what kind of problem
> > are you trying to solve.
> > This should be obvious from the "Abstract" and it's bad if it's not.
> >
> > Best Regards / S pozdravom,
> > Pavol "stick" Rusnak
> > CTO, SatoshiLabs

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Peter D. Gray]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]


I like this proposal and I see it's value: "One seed to rule them all."

Not hard to implement either.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 5A2A5B10


On Fri, Mar 20, 2020 at 03:44:01PM +0000, Ethan Kosakovsky wrote:
> I would like to present a proposal for discussion and peer review. It aims to solve the problem of "too many seeds and too many backups" due to the many reasons stipulated in the proposal text.
> 
> https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-from-bip32.mediawiki
> 
> <pre>
>   BIP:
>   Title: Deterministic Entropy From BIP32 Keychains
>   Author: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
>   Comments-Summary: No comments yet.
>   Comments-URI:
>   Status: Proposed
>   Type: Standards Track
>   Created: 2020-03-20
>   License: BSD-2-Clause
>            OPL
> </pre>
> 
> ==Abstract==
> 
> This proposal provides a way to derive entropy from a HD keychain path in order to deterministically derive the initial entropy used to create keychain mnemonics and seeds.
> 
...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 529 bytes --]

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 4429 bytes --]

I agree with the problem statement in this proposal, but not the proposed
solution.

The challenge of safely securing a seed for a single signature is not
insignificant. Blockchain Commons has published procedures that we consider
the current best practices for cold storage in a free book at
http://bit.ly/SmartCustodyBookV101 and in github at
https://github.com/BlockchainCommons/smartcustodybook. It currently
requires a couple of hours and $200 or more of materials (home safe, 2
ledgers, titanium blanks, etc.) to safely product (significantly less time
and money than Glacier Protocol).

Presumably, people are not going to go to this level of protection for too
many keys, thus there needs to be methods to leverage the root seeds that
are properly protected.

Currently Blockchain Commons is working on standards for airgap solutions
for storing and signing from offline keys. Scenarios include using Shamir
and SLIP-39  on an offline device with no-WiFi or Bluetooth, an air-gapped
mobile phone in airplane mode, or another dedicated device (for instance
the SafeKey device if open source was an option). You would use this device
to create and restore seeds, convert seeds from BIP-39 to SLIP-39, derive
HD keys, and then use QR code from the device to transfer the generated
child keys for use by different apps. In some cases, this offline device
could also read QR transactions and sign them. We have working prototypes
of this today.

This technique works fine for online Bitcoin apps that accept child keys in
the form of xprv (or equivalents) such as those our FullyNoded2 iOS wallet
supports, but the problem for other wallets is that you can't go from an
xprv back to a seed — the xprv creation is a one-way hmac-sha512 operation
(still not convinced this was a good decision).

What I think Ethan is proposing is the ability to turn any child derived
xprv key into a new set valid seed words that could be used by a wallet or
other devices that don't understand xprv and will only allow import of new
seeds words. This gets even more complicated if the seed words are not the
standard BIP-39 set (which BTW, are not an ideal set of words, the
selection of the SLIP-39 words is much better).

Though possibly pragmatic, this approach would be a hack – starting with
some raw entropy, convert this to an entropy seed, then to words, then hmac
to xprv, then derive child keys, then convert that child key to a new
entropy seed, then hmac to xprv, and then derive child keys again, etc.

I'd really prefer to start with finding standards ways to protect the
entropy seed (not specifically the bip39 words derived from that but also
as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) that can be
then be used to create other hierarchies of keys using airgap solutions.

For instance, here is what FullyNoded 2 currently uses to restore a Bitcoin
wallet including root seed:

{
  "birthdate": 1584725088,
  "label": "Testnet Single Signature",
  "entropy": "b3b17e8f425bf7b96d68b67867cdc816",
  "walletName": "DEFAULT_EBaiuGgZQS_StandUp",
  "descriptor":
"wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkXTJ4q2PNZBsPL7HiTXXteajiG8wqAGpLVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2CB1ou8sYiGSf6hcujv/0/*)",
  "blockheight": 1
}

Alternatively, FullyNoded 2 can also restore a wallets without the full
seed, so for instance, if this QR restore was missing the entropy field,
only derived child xprv from the descriptor could be used, so no other
accounts could be created but new addresses as children of the xprv could
be created.

The advantage of of an entropy seed storage centered technique is that I
can convert that entropy seed into either BIP39 words, or any number of
SLIP-39 shards, or Lightning words, and back. We are also looking at using
this with the VSS that underlies Schnorr Musig. We can talk other secure
tool makers on how to use this raw entropy for other purposes to create
chains or hierarchies of keys for their unique needs.

Blockchain Common's doesn't have a full architecture for this yet as we are
working on our POC and are seeking suggestions from other wallet vendors
(in particular lightning and non-bitcoin secure services) on requirements.
Let me know if you'd like to participate in the discussions (currently
either Github issues or a Signal group for the group)

— Christopher Allen

[-- Attachment #2: Type: text/html, Size: 5018 bytes --]

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Ethan Kosakovsky]

Chris,

Thank you for taking the time to share your thoughts. I agree there are wide considerations surrounding key handling and storage. I dont think my proposal interferes with that perspective any more than BIP32 itself would. How keys are handled is a separate matter than the cryptography of key derivation and trying to get back to the one single backup that is future proof.

My proposal is not concerned with how the initial master key/seed is generated, just that we have one. My proposal is concerned with how to avoid having to generate more master keys because of the wide adoption of standards that impose restrictions (like BIP39); or the fragmented methods of initialization various wallets; as well as the instances where sharing the BIP39 seed with multiple wallets is undesirable due to security concerns (for example hot and offline wallet); or just plain incompatible standards.

If we were to start everything from scratch, we would obviously do things differently. However, there are already millions of wallets created using existing standards. It's just not possible to reset sadly.

> What I think Ethan is proposing is the ability to turn any child derived
> xprv key into a new set valid seed words that could be used by a wallet or
> other devices that don't understand xprv and will only allow import of new
> seeds words. This gets even more complicated if the seed words are not the
> standard BIP-39 set (which BTW, are not an ideal set of words, the
> selection of the SLIP-39 words is much better).

I am proposing two separate things.

  - that we use fully hardened paths to derive keys in order to derive entropy.
  - that a BIP44 like derivation path can be used to describe what the entropy is intended for

    For example we use the prefix 83696968 (ASCII seed in decimal) `m/83696968'/type'/index'`
      - `type` defines how the entropy will be used
        `0` means use 128 bits of the entropy as input to BIP39, producing a 12 word BIP39 mnemonic
        `4` means use 256 bits of the entropy as the secret exponent to create a compressed WIF (for use as hdseed in Bitcoin Core)

    In this way, we can neatly define the specific use-cases of the entropy maintaining some order.

      - `index` is the key index so we can generate multiple instances of this type of entropy

To answer your question about whether to one-way-transform the resulting k. In practice, k is already safe because it was derived from a fully hardened path which protects the parent tree. However, the purpose here semantically is to be entropy. But k is not entropy, it's a private key on that derivation path. Neither are we exporting and xprv. We want entropy to seed the derivation of something else specified by the `type`. For that reason I consider it important to transform k by way of a hash or hmac. Using HMAC over hash is a decision based on an abundance of caution to ensure ward off unwanted side effects should k be used for a dual purpose, including as a nonce hash(k), where undesirable and unforeseen interactions could occur.

> Though possibly pragmatic, this approach would be a hack – starting with some raw entropy, convert this to an entropy seed, then to words, then hmac to xprv, then derive child keys, then convert that child key to a new entropy seed, then hmac to xprv, and then derive child keys again, etc.

I am not proposing the nesting, although nothing would prohibit it, I'm just proposing one master root key from which all child keychains can be derived and overcome the incompatibilities and impracticalities detailed.

> Let me know if you'd like to participate in the discussions (currently either Github issues or a Signal group for the group)

Sure! What's the URL of the Github?

Ethan


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, March 21, 2020 2:46 AM, Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> I agree with the problem statement in this proposal, but not the proposed solution.
>
> The challenge of safely securing a seed for a single signature is not insignificant. Blockchain Commons has published procedures that we consider the current best practices for cold storage in a free book at http://bit.ly/SmartCustodyBookV101 and in github at https://github.com/BlockchainCommons/smartcustodybook. It currently requires a couple of hours and $200 or more of materials (home safe, 2 ledgers, titanium blanks, etc.) to safely product (significantly less time and money than Glacier Protocol). 
>
> Presumably, people are not going to go to this level of protection for too many keys, thus there needs to be methods to leverage the root seeds that are properly protected.
>
> Currently Blockchain Commons is working on standards for airgap solutions for storing and signing from offline keys. Scenarios include using Shamir and SLIP-39  on an offline device with no-WiFi or Bluetooth, an air-gapped mobile phone in airplane mode, or another dedicated device (for instance the SafeKey device if open source was an option). You would use this device to create and restore seeds, convert seeds from BIP-39 to SLIP-39, derive HD keys, and then use QR code from the device to transfer the generated child keys for use by different apps. In some cases, this offline device could also read QR transactions and sign them. We have working prototypes of this today.
>
> This technique works fine for online Bitcoin apps that accept child keys in the form of xprv (or equivalents) such as those our FullyNoded2 iOS wallet supports, but the problem for other wallets is that you can't go from an xprv back to a seed — the xprv creation is a one-way hmac-sha512 operation (still not convinced this was a good decision). 
>
> What I think Ethan is proposing is the ability to turn any child derived xprv key into a new set valid seed words that could be used by a wallet or other devices that don't understand xprv and will only allow import of new seeds words. This gets even more complicated if the seed words are not the standard BIP-39 set (which BTW, are not an ideal set of words, the selection of the SLIP-39 words is much better). 
>
> Though possibly pragmatic, this approach would be a hack – starting with some raw entropy, convert this to an entropy seed, then to words, then hmac to xprv, then derive child keys, then convert that child key to a new entropy seed, then hmac to xprv, and then derive child keys again, etc.
>
> I'd really prefer to start with finding standards ways to protect the entropy seed (not specifically the bip39 words derived from that but also as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) that can be then be used to create other hierarchies of keys using airgap solutions.
>
> For instance, here is what FullyNoded 2 currently uses to restore a Bitcoin wallet including root seed:
>
> {
>   "birthdate": 1584725088,
>   "label": "Testnet Single Signature",
>   "entropy": "b3b17e8f425bf7b96d68b67867cdc816",
>   "walletName": "DEFAULT_EBaiuGgZQS_StandUp",
>   "descriptor": "wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkXTJ4q2PNZBsPL7HiTXXteajiG8wqAGpLVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2CB1ou8sYiGSf6hcujv/0/*)",
>   "blockheight": 1
> }
>
> Alternatively, FullyNoded 2 can also restore a wallets without the full seed, so for instance, if this QR restore was missing the entropy field, only derived child xprv from the descriptor could be used, so no other accounts could be created but new addresses as children of the xprv could be created.
>
> The advantage of of an entropy seed storage centered technique is that I can convert that entropy seed into either BIP39 words, or any number of SLIP-39 shards, or Lightning words, and back. We are also looking at using this with the VSS that underlies Schnorr Musig. We can talk other secure tool makers on how to use this raw entropy for other purposes to create chains or hierarchies of keys for their unique needs.
>
> Blockchain Common's doesn't have a full architecture for this yet as we are working on our POC and are seeking suggestions from other wallet vendors (in particular lightning and non-bitcoin secure services) on requirements. Let me know if you'd like to participate in the discussions (currently either Github issues or a Signal group for the group)
>
> — Christopher Allen

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Ethan Kosakovsky]

I have completely revised the wording of this proposal I hope to be clearer in explaining the motivation and methodology.

https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d6

Ethan

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 20, 2020 4:44 PM, Ethan Kosakovsky via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to present a proposal for discussion and peer review. It aims to solve the problem of "too many seeds and too many backups" due to the many reasons stipulated in the proposal text.
>
> https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-from-bip32.mediawiki
>
> <pre>
> BIP:
> Title: Deterministic Entropy From BIP32 Keychains
> Author: Ethan Kosakovsky ethankosakovsky@protonmail.com
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-03-20
> License: BSD-2-Clause
> OPL
> </pre>
>
> ==Abstract==
>
> This proposal provides a way to derive entropy from a HD keychain path in order to deterministically derive the initial entropy used to create keychain mnemonics and seeds.
>
> ==Motivation==
>
> BIP32 uses some initial entropy as a seed to deterministically derive a BIP32 root for hierarchical deterministic keychains. BIP39 introduced a method of encoding initial entropy into a mnemonic phrase which is used as input to a one way hash function in order to deterministically derive a BIP32 seed. The motivation behind mnemonic phrases was to make it easier for humans to backup and store offline. There are also other variations of this theme.
>
> The initial motivation of BIP32 was to make handling of large numbers of private keys easier to manage and backup, since you only need one BIP32 seed to cover all possible keys in the keychain. In practice however, due to various wallet implementations and security models, the average user may be faced with the need to handle an ever growing number of seeds/mnemonics. This is due to incompatible wallet standards, hardware wallets (HWW), seed formats and standards, as well as, the need to used a mix of hot and cold wallets depending on the application and environment.
>
> Examples would span wallets on mobile phones, online servers running protocols like Join Market or Lightning, and the difference between Electrum and BIP39 mnemonic seed formats. The reference implementation of Bitcoin Core uses BIP32, while other cryptocurrencies like Monero use different mnemonic encoding schemes.
>
> We must also consider the different variety of physical backups including paper, metal and other physical storage devices, as well as the potentially splitting backups across different geographical locations. This complexity may result in less care being taken with subsequently generated seeds for new wallets need to be stored and it ultimately results in less security. In reality, the idea of having "one seed for all" has proven to be more difficult in practice than originally thought.
>
> Since all these derivation schemes are deterministic based on some initial entropy, this proposal aims to solve the above problems by detailing a way to deterministically derive the initial entropy used for new root keychains using a single BIP32 style "master root key". This will allow one root key or mnemonic to derive any variety of different root keychains in whatever format is required (like BIP32 and BIP39 etc).
>
> ==Specification==
>
> Input starts with a BIP32 seed. Derivation scheme uses the format `m/83696968'/type'/index'` where `type` is the final seed type, and `index` in the key index of the hardened child private key.
>
> type
>
> bits
>
> output
>
> 0
>
> 128
>
> 12 word BIP39 mnemonic
>
> 1
>
> 256
>
> 24 word BIP39 mnemonic
>
> 2
>
> 128
>
> 12 word Electrum mnemonic
>
> 3
>
> 256
>
> 24 word Electrum mnemonic
>
> 4
>
> 256
>
> WIF for Bitcoin Core
>
> 5
>
> 256
>
> 25 word Monero mnemonic
>
> Entropy is calculated from the HMAC-SHA512(key=k, msg='bip-entropy-from-bip32') of the derived 32 byte private key (k). Entropy is taken from the result according to the number of bits required. This entropy can then be used as input to derive a mnemonic, wallet etc according to the`type` specified.
>
> ==Compatibility==
>
> In order to maintain the widest compatibility, the input to this function is a BIP32 seed, which may or may not have been derived from a BIP39 like mnemonic scheme. This maintains the original motivation that one backup can store any and all child derivation schemes depending on the user's preference or hardware signing devices. For example, devices that store the HD seed as a BIP39 mnemonic, Electrum seed, or BIP32 root key would all be able to implement this standard.
>
> ==Discussion==
>
> This proposal could be split into multiple discrete BIPs in the same way that BIP32 described the derivation mechanics, BIP39 the input encoding with mnemonics, and the derivation paths like BIP44, BIP49 and BIP84. This has been avoided to reduce complexity. The resulting private key processed with HMAC-SHA512 and truncated as necessary. HMAC-SHA512 was chosen because it may have better compatibility in embedded devices as it's already required in devices supporting BIP32.
>
> ==Test Vectors==
>
> ===Test case 1===
>
> MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind employ giant era attitude exit final oval one finger decorate pair useless super method float toddler dance
> MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfGJNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> PATH: m/83696968'/0'/0'
> BITS REQUIRED: 128
>
> DERIVED CHILD WIF=L3cefeCHyo8jczVjckMxaiPBaPUunc3D8CsjRxYbYp3FhasGpsV3
> DERIVED CHILD k=bed343b04ba0216d9eeebff0366b61c4179d90d44b61c716ef6d568836ba4d23
> CHILD ENTROPY=6458698fae3578b48a64124ea3514e12
> CONVERT ENTROPY TO WIF=KwDiBf89QgGbjEhKnhXJuH7T2Vv72UKQA8KRkmNwVFS2znAS5xb9
> CHILD BIP39 MNEMONIC=gold select glue fragile fiscal fog civil liquid exchange box fatal caught
> CHILD BIP39 SEED=2a2720e5590d4ec3140e51ba1b0b0a5183222c1668977c8a57572b0ea55d238cd8e899b3b1870e48894ca837e41e5d0db07554715efb21556fdde27f9f7ba153
> CHILD BIP32 ROOT KEY=xprv9s21ZrQH143K2ZH5qacptquLGvcYpHSNeyFVCU8Ur4u9kocajbBgcaCbHkGbwDsBR661H29F54j5mz14kwXbY9PZKdNRdjgRcGfshBK9XXb
>
> ===Test case 2===
>
> MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind employ giant era attitude exit final oval one finger decorate pair useless super method float toddler dance
> MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfGJNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> PATH: m/83696968'/1'/0'
> BITS REQUIRED: 256
>
> DERIVED CHILD WIF=L1zCbtnDWUN4vJA3De4sxmJnoRim57CQUuBb4KBoRNs2EMEq2Brg
> DERIVED CHILD k=8e3ca6054a6303f4a6a1bcbda6134c9802f4f0a0d76b0ee6b69b06b1e80b2192
> CHILD ENTROPY=ec4e2f7e2c3fca9a34fa29747bf8ba0ab7f05136f37e134e2457e9e53639670b
> CONVERT ENTROPY TO WIF=L594JSCygt2wBaB9mCpXjiLkkxkEojpBdNXG8UrrdLd2LvPBRMUs
> CHILD BIP39 MNEMONIC=unable imitate test flash witness escape stadium early inner thank company betray lecture chuckle swift hurt battle illness bicycle stable fat bronze order high
> CHILD BIP39 SEED=73509b0e847ee66bddeb098a55063d73e8c6dd5f1c1db6969c668bb54c19bde6eae8acc29a81118d1d9719fa1bc620fee7edd7c15a17bcaf70b0fdfc0c0c3803
> CHILD BIP32 ROOT KEY=xprv9s21ZrQH143K4PfLyyjYLVmKbnUTNFK6Y7jPKWfRZB3iSw1Gy9qowEzkYHfetVabfmjHEEPrcTJbh7chae33Sm9uAjuXzhSL6Li8dcwM9Bm
>
> ===Test case 3===
>
> MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind employ giant era attitude exit final oval one finger decorate pair useless super method float toddler dance
> MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfGJNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> PATH: m/83696968'/4'/0'
> BITS REQUIRED: 256
>
> DERIVED CHILD WIF=KwdD5PYnCU3xQDfFJ6XBf6UDaLrTUxrKmBpdjRuuavWyqAQtpaA2
> DERIVED CHILD k=0c169ce2c17bea08512a7519769e365242a1562bd63c4c903daef516000efbf2
> CHILD ENTROPY=25573247f8a76799f7abc086b9286b5a7ccb03cb8d3550f48ac1e71d90832974
> CONVERT ENTROPY TO WIF=KxUJ8VzMk7uWDEcwYjLRzRMGE6sSpwCfQxkE9GEwAvXhFSDNba9G
> CHILD BIP39 MNEMONIC=census ridge music vanish island smooth team job mammal sing bracket reject smile limit comfort pluck extend picture race soda suit dose place obtain
> CHILD BIP39 SEED=4e5c82be6455ecf0884d9475435e29a9afb9acf70b07296d7e5039c866e4d54647706918b9d14909dfbd7071a4b7aee8a4ad0ac2bf48f0a09a8899dd28564418
> CHILD BIP32 ROOT KEY=xprv9s21ZrQH143K2kekJsK9V6t4ZKwHkY1Q3umxuaAhdZKGxCMpHiddLdYUQBoynszpwnk5upoC788LiT5MZ5q1vUABXG7AMyZK5UjD9iyL7Am
>
> ==References==
>
> BIP32, BIP39
>
> ==Copyright==
>
> This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Tim Ruffing]

I think your proposal is simply to use BIP32 for all derivations and
the observation that you can work with derived keys with the
corresponding suffixes of the path. I believe that this is a good idea.

But I don't think that simply writing a standard will help. It's just
one step. If all your wallets support incompatible formats, we should
work on fixing this because that's the root of the issue. Otherwise you
end up converting keys back and forth manually (as Chris pointed out),
and this can't be the goal. 

But then you need to reach out to wallet devs explicitly and get them
involved in creating the standard. Otherwise they won't use it. That's
a hard process, and it's even harder to make sure that the resulting
proposal isn't way too complex because everyone brings their special
case to the table. 

Tim 

On Sun, 2020-03-22 at 11:58 +0000, Ethan Kosakovsky via bitcoin-dev
wrote:
> I have completely revised the wording of this proposal I hope to be
> clearer in explaining the motivation and methodology.
> 
> https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d6
> 
> Ethan
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, March 20, 2020 4:44 PM, Ethan Kosakovsky via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > I would like to present a proposal for discussion and peer review.
> > It aims to solve the problem of "too many seeds and too many
> > backups" due to the many reasons stipulated in the proposal text.
> > 
> > https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-from-bip32.mediawiki
> > 
> > <pre>
> > BIP:
> > Title: Deterministic Entropy From BIP32 Keychains
> > Author: Ethan Kosakovsky ethankosakovsky@protonmail.com
> > Comments-Summary: No comments yet.
> > Comments-URI:
> > Status: Proposed
> > Type: Standards Track
> > Created: 2020-03-20
> > License: BSD-2-Clause
> > OPL
> > </pre>
> > 
> > ==Abstract==
> > 
> > This proposal provides a way to derive entropy from a HD keychain
> > path in order to deterministically derive the initial entropy used
> > to create keychain mnemonics and seeds.
> > 
> > ==Motivation==
> > 
> > BIP32 uses some initial entropy as a seed to deterministically
> > derive a BIP32 root for hierarchical deterministic keychains. BIP39
> > introduced a method of encoding initial entropy into a mnemonic
> > phrase which is used as input to a one way hash function in order
> > to deterministically derive a BIP32 seed. The motivation behind
> > mnemonic phrases was to make it easier for humans to backup and
> > store offline. There are also other variations of this theme.
> > 
> > The initial motivation of BIP32 was to make handling of large
> > numbers of private keys easier to manage and backup, since you only
> > need one BIP32 seed to cover all possible keys in the keychain. In
> > practice however, due to various wallet implementations and
> > security models, the average user may be faced with the need to
> > handle an ever growing number of seeds/mnemonics. This is due to
> > incompatible wallet standards, hardware wallets (HWW), seed formats
> > and standards, as well as, the need to used a mix of hot and cold
> > wallets depending on the application and environment.
> > 
> > Examples would span wallets on mobile phones, online servers
> > running protocols like Join Market or Lightning, and the difference
> > between Electrum and BIP39 mnemonic seed formats. The reference
> > implementation of Bitcoin Core uses BIP32, while other
> > cryptocurrencies like Monero use different mnemonic encoding
> > schemes.
> > 
> > We must also consider the different variety of physical backups
> > including paper, metal and other physical storage devices, as well
> > as the potentially splitting backups across different geographical
> > locations. This complexity may result in less care being taken with
> > subsequently generated seeds for new wallets need to be stored and
> > it ultimately results in less security. In reality, the idea of
> > having "one seed for all" has proven to be more difficult in
> > practice than originally thought.
> > 
> > Since all these derivation schemes are deterministic based on some
> > initial entropy, this proposal aims to solve the above problems by
> > detailing a way to deterministically derive the initial entropy
> > used for new root keychains using a single BIP32 style "master root
> > key". This will allow one root key or mnemonic to derive any
> > variety of different root keychains in whatever format is required
> > (like BIP32 and BIP39 etc).
> > 
> > ==Specification==
> > 
> > Input starts with a BIP32 seed. Derivation scheme uses the format
> > `m/83696968'/type'/index'` where `type` is the final seed type, and
> > `index` in the key index of the hardened child private key.
> > 
> > type
> > 
> > bits
> > 
> > output
> > 
> > 0
> > 
> > 128
> > 
> > 12 word BIP39 mnemonic
> > 
> > 1
> > 
> > 256
> > 
> > 24 word BIP39 mnemonic
> > 
> > 2
> > 
> > 128
> > 
> > 12 word Electrum mnemonic
> > 
> > 3
> > 
> > 256
> > 
> > 24 word Electrum mnemonic
> > 
> > 4
> > 
> > 256
> > 
> > WIF for Bitcoin Core
> > 
> > 5
> > 
> > 256
> > 
> > 25 word Monero mnemonic
> > 
> > Entropy is calculated from the HMAC-SHA512(key=k, msg='bip-entropy-
> > from-bip32') of the derived 32 byte private key (k). Entropy is
> > taken from the result according to the number of bits required.
> > This entropy can then be used as input to derive a mnemonic, wallet
> > etc according to the`type` specified.
> > 
> > ==Compatibility==
> > 
> > In order to maintain the widest compatibility, the input to this
> > function is a BIP32 seed, which may or may not have been derived
> > from a BIP39 like mnemonic scheme. This maintains the original
> > motivation that one backup can store any and all child derivation
> > schemes depending on the user's preference or hardware signing
> > devices. For example, devices that store the HD seed as a BIP39
> > mnemonic, Electrum seed, or BIP32 root key would all be able to
> > implement this standard.
> > 
> > ==Discussion==
> > 
> > This proposal could be split into multiple discrete BIPs in the
> > same way that BIP32 described the derivation mechanics, BIP39 the
> > input encoding with mnemonics, and the derivation paths like BIP44,
> > BIP49 and BIP84. This has been avoided to reduce complexity. The
> > resulting private key processed with HMAC-SHA512 and truncated as
> > necessary. HMAC-SHA512 was chosen because it may have better
> > compatibility in embedded devices as it's already required in
> > devices supporting BIP32.
> > 
> > ==Test Vectors==
> > 
> > ===Test case 1===
> > 
> > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > employ giant era attitude exit final oval one finger decorate pair
> > useless super method float toddler dance
> > MASTER BIP32 ROOT KEY:
> > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > PATH: m/83696968'/0'/0'
> > BITS REQUIRED: 128
> > 
> > DERIVED CHILD
> > WIF=L3cefeCHyo8jczVjckMxaiPBaPUunc3D8CsjRxYbYp3FhasGpsV3
> > DERIVED CHILD
> > k=bed343b04ba0216d9eeebff0366b61c4179d90d44b61c716ef6d568836ba4d23
> > CHILD ENTROPY=6458698fae3578b48a64124ea3514e12
> > CONVERT ENTROPY TO
> > WIF=KwDiBf89QgGbjEhKnhXJuH7T2Vv72UKQA8KRkmNwVFS2znAS5xb9
> > CHILD BIP39 MNEMONIC=gold select glue fragile fiscal fog civil
> > liquid exchange box fatal caught
> > CHILD BIP39
> > SEED=2a2720e5590d4ec3140e51ba1b0b0a5183222c1668977c8a57572b0ea55d23
> > 8cd8e899b3b1870e48894ca837e41e5d0db07554715efb21556fdde27f9f7ba153
> > CHILD BIP32 ROOT
> > KEY=xprv9s21ZrQH143K2ZH5qacptquLGvcYpHSNeyFVCU8Ur4u9kocajbBgcaCbHkG
> > bwDsBR661H29F54j5mz14kwXbY9PZKdNRdjgRcGfshBK9XXb
> > 
> > ===Test case 2===
> > 
> > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > employ giant era attitude exit final oval one finger decorate pair
> > useless super method float toddler dance
> > MASTER BIP32 ROOT KEY:
> > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > PATH: m/83696968'/1'/0'
> > BITS REQUIRED: 256
> > 
> > DERIVED CHILD
> > WIF=L1zCbtnDWUN4vJA3De4sxmJnoRim57CQUuBb4KBoRNs2EMEq2Brg
> > DERIVED CHILD
> > k=8e3ca6054a6303f4a6a1bcbda6134c9802f4f0a0d76b0ee6b69b06b1e80b2192
> > CHILD
> > ENTROPY=ec4e2f7e2c3fca9a34fa29747bf8ba0ab7f05136f37e134e2457e9e5363
> > 9670b
> > CONVERT ENTROPY TO
> > WIF=L594JSCygt2wBaB9mCpXjiLkkxkEojpBdNXG8UrrdLd2LvPBRMUs
> > CHILD BIP39 MNEMONIC=unable imitate test flash witness escape
> > stadium early inner thank company betray lecture chuckle swift hurt
> > battle illness bicycle stable fat bronze order high
> > CHILD BIP39
> > SEED=73509b0e847ee66bddeb098a55063d73e8c6dd5f1c1db6969c668bb54c19bd
> > e6eae8acc29a81118d1d9719fa1bc620fee7edd7c15a17bcaf70b0fdfc0c0c3803
> > CHILD BIP32 ROOT
> > KEY=xprv9s21ZrQH143K4PfLyyjYLVmKbnUTNFK6Y7jPKWfRZB3iSw1Gy9qowEzkYHf
> > etVabfmjHEEPrcTJbh7chae33Sm9uAjuXzhSL6Li8dcwM9Bm
> > 
> > ===Test case 3===
> > 
> > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > employ giant era attitude exit final oval one finger decorate pair
> > useless super method float toddler dance
> > MASTER BIP32 ROOT KEY:
> > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > PATH: m/83696968'/4'/0'
> > BITS REQUIRED: 256
> > 
> > DERIVED CHILD
> > WIF=KwdD5PYnCU3xQDfFJ6XBf6UDaLrTUxrKmBpdjRuuavWyqAQtpaA2
> > DERIVED CHILD
> > k=0c169ce2c17bea08512a7519769e365242a1562bd63c4c903daef516000efbf2
> > CHILD
> > ENTROPY=25573247f8a76799f7abc086b9286b5a7ccb03cb8d3550f48ac1e71d908
> > 32974
> > CONVERT ENTROPY TO
> > WIF=KxUJ8VzMk7uWDEcwYjLRzRMGE6sSpwCfQxkE9GEwAvXhFSDNba9G
> > CHILD BIP39 MNEMONIC=census ridge music vanish island smooth team
> > job mammal sing bracket reject smile limit comfort pluck extend
> > picture race soda suit dose place obtain
> > CHILD BIP39
> > SEED=4e5c82be6455ecf0884d9475435e29a9afb9acf70b07296d7e5039c866e4d5
> > 4647706918b9d14909dfbd7071a4b7aee8a4ad0ac2bf48f0a09a8899dd28564418
> > CHILD BIP32 ROOT
> > KEY=xprv9s21ZrQH143K2kekJsK9V6t4ZKwHkY1Q3umxuaAhdZKGxCMpHiddLdYUQBo
> > ynszpwnk5upoC788LiT5MZ5q1vUABXG7AMyZK5UjD9iyL7Am
> > 
> > ==References==
> > 
> > BIP32, BIP39
> > 
> > ==Copyright==
> > 
> > This BIP is dual-licensed under the Open Publication License and
> > BSD 2-clause license.
> > 
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Adam Back]

I think the point is to use this proposed extension/standard for a
kind of "seed management" function, set it up on an offline device (an
always offline laptop, or a modified hardware wallet) where you put
the master seed.  And then you use this as a kind of seed manager and
transcript the seeds for different sub-wallets into the respective
wallets as BIP39 mnemonics.

So I do not think it needs any changes from existing wallet authors,
as the interaction point is a bip 39 seed, which they mostly know how
to use.  Indeed if you were to modify an existing wallet to accept the
master seed from seed management scheme and derive the seed it needs
on each wallet, then that would create a weakest link in the chain
risk - if that wallet was insecure, or compromised then all other
derived seeds would be also and you want independence for each wallet.

I do think that this use case is a practical problem for people
managing multiple seeds for various wallets in a bitcoin business
setting or even power users - you lose the single backup design,
because it's too cumbersome to create fresh backups for each of
multiple wallets, especially distributed , fireproof cryptosteel etc
backups and so in practice for multi wallet scenarios probably they
are not all full backed up or not backed up as robustly (not as
geo-redundant, fireproof, secret-shared etc).

Adam

On Tue, 24 Mar 2020 at 09:32, Tim Ruffing via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I think your proposal is simply to use BIP32 for all derivations and
> the observation that you can work with derived keys with the
> corresponding suffixes of the path. I believe that this is a good idea.
>
> But I don't think that simply writing a standard will help. It's just
> one step. If all your wallets support incompatible formats, we should
> work on fixing this because that's the root of the issue. Otherwise you
> end up converting keys back and forth manually (as Chris pointed out),
> and this can't be the goal.
>
> But then you need to reach out to wallet devs explicitly and get them
> involved in creating the standard. Otherwise they won't use it. That's
> a hard process, and it's even harder to make sure that the resulting
> proposal isn't way too complex because everyone brings their special
> case to the table.
>
> Tim
>
> On Sun, 2020-03-22 at 11:58 +0000, Ethan Kosakovsky via bitcoin-dev
> wrote:
> > I have completely revised the wording of this proposal I hope to be
> > clearer in explaining the motivation and methodology.
> >
> > https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d6
> >
> > Ethan
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, March 20, 2020 4:44 PM, Ethan Kosakovsky via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > I would like to present a proposal for discussion and peer review.
> > > It aims to solve the problem of "too many seeds and too many
> > > backups" due to the many reasons stipulated in the proposal text.
> > >
> > > https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-from-bip32.mediawiki
> > >
> > > <pre>
> > > BIP:
> > > Title: Deterministic Entropy From BIP32 Keychains
> > > Author: Ethan Kosakovsky ethankosakovsky@protonmail.com
> > > Comments-Summary: No comments yet.
> > > Comments-URI:
> > > Status: Proposed
> > > Type: Standards Track
> > > Created: 2020-03-20
> > > License: BSD-2-Clause
> > > OPL
> > > </pre>
> > >
> > > ==Abstract==
> > >
> > > This proposal provides a way to derive entropy from a HD keychain
> > > path in order to deterministically derive the initial entropy used
> > > to create keychain mnemonics and seeds.
> > >
> > > ==Motivation==
> > >
> > > BIP32 uses some initial entropy as a seed to deterministically
> > > derive a BIP32 root for hierarchical deterministic keychains. BIP39
> > > introduced a method of encoding initial entropy into a mnemonic
> > > phrase which is used as input to a one way hash function in order
> > > to deterministically derive a BIP32 seed. The motivation behind
> > > mnemonic phrases was to make it easier for humans to backup and
> > > store offline. There are also other variations of this theme.
> > >
> > > The initial motivation of BIP32 was to make handling of large
> > > numbers of private keys easier to manage and backup, since you only
> > > need one BIP32 seed to cover all possible keys in the keychain. In
> > > practice however, due to various wallet implementations and
> > > security models, the average user may be faced with the need to
> > > handle an ever growing number of seeds/mnemonics. This is due to
> > > incompatible wallet standards, hardware wallets (HWW), seed formats
> > > and standards, as well as, the need to used a mix of hot and cold
> > > wallets depending on the application and environment.
> > >
> > > Examples would span wallets on mobile phones, online servers
> > > running protocols like Join Market or Lightning, and the difference
> > > between Electrum and BIP39 mnemonic seed formats. The reference
> > > implementation of Bitcoin Core uses BIP32, while other
> > > cryptocurrencies like Monero use different mnemonic encoding
> > > schemes.
> > >
> > > We must also consider the different variety of physical backups
> > > including paper, metal and other physical storage devices, as well
> > > as the potentially splitting backups across different geographical
> > > locations. This complexity may result in less care being taken with
> > > subsequently generated seeds for new wallets need to be stored and
> > > it ultimately results in less security. In reality, the idea of
> > > having "one seed for all" has proven to be more difficult in
> > > practice than originally thought.
> > >
> > > Since all these derivation schemes are deterministic based on some
> > > initial entropy, this proposal aims to solve the above problems by
> > > detailing a way to deterministically derive the initial entropy
> > > used for new root keychains using a single BIP32 style "master root
> > > key". This will allow one root key or mnemonic to derive any
> > > variety of different root keychains in whatever format is required
> > > (like BIP32 and BIP39 etc).
> > >
> > > ==Specification==
> > >
> > > Input starts with a BIP32 seed. Derivation scheme uses the format
> > > `m/83696968'/type'/index'` where `type` is the final seed type, and
> > > `index` in the key index of the hardened child private key.
> > >
> > > type
> > >
> > > bits
> > >
> > > output
> > >
> > > 0
> > >
> > > 128
> > >
> > > 12 word BIP39 mnemonic
> > >
> > > 1
> > >
> > > 256
> > >
> > > 24 word BIP39 mnemonic
> > >
> > > 2
> > >
> > > 128
> > >
> > > 12 word Electrum mnemonic
> > >
> > > 3
> > >
> > > 256
> > >
> > > 24 word Electrum mnemonic
> > >
> > > 4
> > >
> > > 256
> > >
> > > WIF for Bitcoin Core
> > >
> > > 5
> > >
> > > 256
> > >
> > > 25 word Monero mnemonic
> > >
> > > Entropy is calculated from the HMAC-SHA512(key=k, msg='bip-entropy-
> > > from-bip32') of the derived 32 byte private key (k). Entropy is
> > > taken from the result according to the number of bits required.
> > > This entropy can then be used as input to derive a mnemonic, wallet
> > > etc according to the`type` specified.
> > >
> > > ==Compatibility==
> > >
> > > In order to maintain the widest compatibility, the input to this
> > > function is a BIP32 seed, which may or may not have been derived
> > > from a BIP39 like mnemonic scheme. This maintains the original
> > > motivation that one backup can store any and all child derivation
> > > schemes depending on the user's preference or hardware signing
> > > devices. For example, devices that store the HD seed as a BIP39
> > > mnemonic, Electrum seed, or BIP32 root key would all be able to
> > > implement this standard.
> > >
> > > ==Discussion==
> > >
> > > This proposal could be split into multiple discrete BIPs in the
> > > same way that BIP32 described the derivation mechanics, BIP39 the
> > > input encoding with mnemonics, and the derivation paths like BIP44,
> > > BIP49 and BIP84. This has been avoided to reduce complexity. The
> > > resulting private key processed with HMAC-SHA512 and truncated as
> > > necessary. HMAC-SHA512 was chosen because it may have better
> > > compatibility in embedded devices as it's already required in
> > > devices supporting BIP32.
> > >
> > > ==Test Vectors==
> > >
> > > ===Test case 1===
> > >
> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > > employ giant era attitude exit final oval one finger decorate pair
> > > useless super method float toddler dance
> > > MASTER BIP32 ROOT KEY:
> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > > PATH: m/83696968'/0'/0'
> > > BITS REQUIRED: 128
> > >
> > > DERIVED CHILD
> > > WIF=L3cefeCHyo8jczVjckMxaiPBaPUunc3D8CsjRxYbYp3FhasGpsV3
> > > DERIVED CHILD
> > > k=bed343b04ba0216d9eeebff0366b61c4179d90d44b61c716ef6d568836ba4d23
> > > CHILD ENTROPY=6458698fae3578b48a64124ea3514e12
> > > CONVERT ENTROPY TO
> > > WIF=KwDiBf89QgGbjEhKnhXJuH7T2Vv72UKQA8KRkmNwVFS2znAS5xb9
> > > CHILD BIP39 MNEMONIC=gold select glue fragile fiscal fog civil
> > > liquid exchange box fatal caught
> > > CHILD BIP39
> > > SEED=2a2720e5590d4ec3140e51ba1b0b0a5183222c1668977c8a57572b0ea55d23
> > > 8cd8e899b3b1870e48894ca837e41e5d0db07554715efb21556fdde27f9f7ba153
> > > CHILD BIP32 ROOT
> > > KEY=xprv9s21ZrQH143K2ZH5qacptquLGvcYpHSNeyFVCU8Ur4u9kocajbBgcaCbHkG
> > > bwDsBR661H29F54j5mz14kwXbY9PZKdNRdjgRcGfshBK9XXb
> > >
> > > ===Test case 2===
> > >
> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > > employ giant era attitude exit final oval one finger decorate pair
> > > useless super method float toddler dance
> > > MASTER BIP32 ROOT KEY:
> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > > PATH: m/83696968'/1'/0'
> > > BITS REQUIRED: 256
> > >
> > > DERIVED CHILD
> > > WIF=L1zCbtnDWUN4vJA3De4sxmJnoRim57CQUuBb4KBoRNs2EMEq2Brg
> > > DERIVED CHILD
> > > k=8e3ca6054a6303f4a6a1bcbda6134c9802f4f0a0d76b0ee6b69b06b1e80b2192
> > > CHILD
> > > ENTROPY=ec4e2f7e2c3fca9a34fa29747bf8ba0ab7f05136f37e134e2457e9e5363
> > > 9670b
> > > CONVERT ENTROPY TO
> > > WIF=L594JSCygt2wBaB9mCpXjiLkkxkEojpBdNXG8UrrdLd2LvPBRMUs
> > > CHILD BIP39 MNEMONIC=unable imitate test flash witness escape
> > > stadium early inner thank company betray lecture chuckle swift hurt
> > > battle illness bicycle stable fat bronze order high
> > > CHILD BIP39
> > > SEED=73509b0e847ee66bddeb098a55063d73e8c6dd5f1c1db6969c668bb54c19bd
> > > e6eae8acc29a81118d1d9719fa1bc620fee7edd7c15a17bcaf70b0fdfc0c0c3803
> > > CHILD BIP32 ROOT
> > > KEY=xprv9s21ZrQH143K4PfLyyjYLVmKbnUTNFK6Y7jPKWfRZB3iSw1Gy9qowEzkYHf
> > > etVabfmjHEEPrcTJbh7chae33Sm9uAjuXzhSL6Li8dcwM9Bm
> > >
> > > ===Test case 3===
> > >
> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > > employ giant era attitude exit final oval one finger decorate pair
> > > useless super method float toddler dance
> > > MASTER BIP32 ROOT KEY:
> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > > PATH: m/83696968'/4'/0'
> > > BITS REQUIRED: 256
> > >
> > > DERIVED CHILD
> > > WIF=KwdD5PYnCU3xQDfFJ6XBf6UDaLrTUxrKmBpdjRuuavWyqAQtpaA2
> > > DERIVED CHILD
> > > k=0c169ce2c17bea08512a7519769e365242a1562bd63c4c903daef516000efbf2
> > > CHILD
> > > ENTROPY=25573247f8a76799f7abc086b9286b5a7ccb03cb8d3550f48ac1e71d908
> > > 32974
> > > CONVERT ENTROPY TO
> > > WIF=KxUJ8VzMk7uWDEcwYjLRzRMGE6sSpwCfQxkE9GEwAvXhFSDNba9G
> > > CHILD BIP39 MNEMONIC=census ridge music vanish island smooth team
> > > job mammal sing bracket reject smile limit comfort pluck extend
> > > picture race soda suit dose place obtain
> > > CHILD BIP39
> > > SEED=4e5c82be6455ecf0884d9475435e29a9afb9acf70b07296d7e5039c866e4d5
> > > 4647706918b9d14909dfbd7071a4b7aee8a4ad0ac2bf48f0a09a8899dd28564418
> > > CHILD BIP32 ROOT
> > > KEY=xprv9s21ZrQH143K2kekJsK9V6t4ZKwHkY1Q3umxuaAhdZKGxCMpHiddLdYUQBo
> > > ynszpwnk5upoC788LiT5MZ5q1vUABXG7AMyZK5UjD9iyL7Am
> > >
> > > ==References==
> > >
> > > BIP32, BIP39
> > >
> > > ==Copyright==
> > >
> > > This BIP is dual-licensed under the Open Publication License and
> > > BSD 2-clause license.
> > >
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev