Ethan Kosakovsky [ARCHIVE] on Nostr: 📅 Original date posted:2020-03-20 📝 Original message:I think my proposal can be ...
📅 Original date posted:2020-03-20
📝 Original message: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 at 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 at 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
📝 Original message: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 at 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 at 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