From: Ethan Kosakovsky <ethankosakovsky@protonmail•com>
To: Pavol Rusnak <stick@satoshilabs•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains
Date: Fri, 20 Mar 2020 17:34:05 +0000 [thread overview]
Message-ID: <x3wT5bNuZTOXW6pY5-zsu-5BOKYMRqrEoyOaK0kSpprkj7ikNhsLvzBoNqK1_KcWhnsn80Ld0f1jZdhZ4xol0rjnBtxbpH5fm3f2yKTGsVk=@protonmail.com> (raw)
In-Reply-To: <4cc5041f-3960-8f42-256f-5e00e12d05c5@satoshilabs.com>
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
next prev parent reply other threads:[~2020-03-20 17:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-20 15:44 Ethan Kosakovsky
2020-03-20 16:29 ` Pavol Rusnak
2020-03-20 17:34 ` Ethan Kosakovsky [this message]
2020-03-20 17:35 ` Ethan Kosakovsky
2020-03-20 20:02 ` Peter D. Gray
2020-03-21 1:46 ` Christopher Allen
2020-03-21 15:10 ` Ethan Kosakovsky
2020-03-22 11:58 ` Ethan Kosakovsky
2020-03-24 8:07 ` Tim Ruffing
2020-03-25 13:54 ` Adam Back
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='x3wT5bNuZTOXW6pY5-zsu-5BOKYMRqrEoyOaK0kSpprkj7ikNhsLvzBoNqK1_KcWhnsn80Ld0f1jZdhZ4xol0rjnBtxbpH5fm3f2yKTGsVk=@protonmail.com' \
--to=ethankosakovsky@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=stick@satoshilabs$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox