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