Date: Fri, 20 Mar 2020 17:35:13 +0000
To: Pavol Rusnak <stick@satoshilabs.com>
From: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
Reply-To: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
Message-ID: <k30xrtCAvArvTk-CMOGYZO7dVLYnnxkH1NJCDVrmNP_d75_sy9ljZ7bwW5UyRe4x6f3W3b476D4YnnXiWOX_gYiH7fdgT65UvRyzVvvVZcg=@protonmail.com>
In-Reply-To: <x3wT5bNuZTOXW6pY5-zsu-5BOKYMRqrEoyOaK0kSpprkj7ikNhsLvzBoNqK1_KcWhnsn80Ld0f1jZdhZ4xol0rjnBtxbpH5fm3f2yKTGsVk=@protonmail.com>
References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com>
 <4cc5041f-3960-8f42-256f-5e00e12d05c5@satoshilabs.com>
 <x3wT5bNuZTOXW6pY5-zsu-5BOKYMRqrEoyOaK0kSpprkj7ikNhsLvzBoNqK1_KcWhnsn80Ld0f1jZdhZ4xol0rjnBtxbpH5fm3f2yKTGsVk=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains
Precedence: list

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

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Friday, March 20, 2020 6:34 PM, Ethan Kosakovsky <ethankosakovsky@proton=
mail.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 don=
t 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 a=
re effectively hot wallets.
>
>     The problem is BIP39. BIP32 is fine but the backup process is not hum=
an 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 entro=
py by hash-stretching the initial entropy.
>
>     We can already export keychains from BIP32, as xprvs, but there is al=
so no easy way to make as a human readable/typeable like BIP39 mnemonics. M=
ost 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, s=
o practically speaking if I want to use multiple wallets and cannot share a=
n 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. B=
IP39 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 "maste=
r root key". From there it makes a BIP32 keychain and I can deterministical=
ly create child BIP39 seeds by taking a hardened path, using the private ke=
y 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
>
>     =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origi=
nal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90
>     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