From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 61A57C07FF for ; Fri, 20 Mar 2020 17:35:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 4FD89876F7 for ; Fri, 20 Mar 2020 17:35:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbQqEGzwTMLd for ; Fri, 20 Mar 2020 17:35:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by whitealder.osuosl.org (Postfix) with ESMTPS id 44CC3876BD for ; Fri, 20 Mar 2020 17:35:22 +0000 (UTC) Date: Fri, 20 Mar 2020 17:35:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1584725718; bh=44iYOQPNVpI6We1HMDFrNA5KBadCRLy6gMcbUGtXksA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=u1m3Ckm39cMrnH48jGefiLNE7YUxMIuCzv2MGrUJqLnzXd2SHQZ19of6LG0JDhtBp vrOAEsk7c4f8PzrLVcSprqUsu20PfzHIZwxuEPOSKvx2PdXXQ12iiRMeWiwOnbM692 7Y8is277Zdaj+QgkqnV91ro2jm/W5Qjav6+n6mEM= To: Pavol Rusnak From: Ethan Kosakovsky Reply-To: Ethan Kosakovsky Message-ID: In-Reply-To: References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com> <4cc5041f-3960-8f42-256f-5e00e12d05c5@satoshilabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 20 Mar 2020 17:58:13 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 17:35:24 -0000 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 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