Greetings,

After reading and implementing BIP-85 <https://github.com/akarve/bipsea> I 
entertained the possibility of a generalized keychain application atop 
hierarchical deterministic wallets.

Here is the pre-proposal for said BIP-Keychain on GitHub 
<https://github.com/akarve/bip-keychain>. Below are the Abstract and 
Motivation. See the link above for the full spec.

Let me know if I should proceed to submit this as a proper BIP.

Thank you.


# Abstract

We extend the hierarchical deterministic wallet chain from BIP-32 with a new
application code for BIP-85 and a deterministic path derivation algorithm
that allows applications to create a large key-value map of secrets where 
the key
for each secret is a meaningful semantic path, as opposed to an arbitrary 
integer.
This secure key-value map can replace modern password managers and offers 
an improved, possibly trustless security profile.

# Motivation

BIP-85 specifies how to derive passwords, private keys, and entropy from 
paths
with the following form:

```
m/83696968'/{app_no}'/{index}'
```

Nevertheless BIP-85 has the following ambiguities and shortcomings:

1. Path construction is arbitrary in that there is no well-defined 
procedure to
extend the path for applications that require more than two parameters.
The implied convention is for paths to end with `{some_integer_n}'{index}'`
but there is no guidance on the order of parameters for applications that 
need more
than two inputs.

1. Return types for applications vary in interpretation and are
not specific enough to be actionable. For example sometimes `n` represents 
the
number of bytes, sometimes the number of characters, sometimes the number of
BIP-39 words, etc.

Moreover, modern password managers protect hot child secrets with a single 
root
master hot secret such that if the master secret is compromised all 
children are
also compromised.

BIP-Keychain proposes a new paradigm where numerous hot or cold secrets are 
derived
from hot but non-secret-compromising _derivation path keys_ that are in 
turn stored
under a hot master secret such that if this hot master is compromised only 
the
_derivation path keys_, and not the actual child secrets (_derivation path 
values_),
are compromised. Said hot master secret can itself be the child derivative 
of a
cold master key. The master key for deriving the secret values need not be 
stored
online nor with the derivation path keys and may be provided just-in-time 
by the
application.

Moreover, _generalized derivation paths_ may be interpreted not simply as an
input to key derivation but also as information about the real world. 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6d012560-4a66-4346-a1e8-8d8e5c879b29n%40googlegroups.com.