OR13
commented
4 years ago https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#public-child-key-derivation
As mentioned previously, a very useful characteristic of HD wallets is the ability to derive public child keys from public parent keys, without having the private keys. This gives us two ways to derive a child public key: either from the child private key, or directly from the parent public key.
An extended public key can be used, therefore, to derive all of the public keys (and only the public keys) in that branch of the HD wallet structure.
This shortcut can be used to create very secure public key–only deployments where a server or application has a copy of an extended public key and no private keys whatsoever. That kind of deployment can produce an infinite number of public keys and bitcoin addresses, but cannot spend any of the money sent to those addresses. Meanwhile, on another, more secure server, the extended private key can derive all the corresponding private keys to sign transactions and spend the money.
One common application of this solution is to install an extended public key on a web server that serves an ecommerce application. The web server can use the public key derivation function to create a new bitcoin address for every transaction (e.g., for a customer shopping cart). The web server will not have any private keys that would be vulnerable to theft. Without HD wallets, the only way to do this is to generate thousands of bitcoin addresses on a separate secure server and then preload them on the ecommerce server. That approach is cumbersome and requires constant maintenance to ensure that the ecommerce server doesn’t "run out" of keys.
So essentially, I'm suggesting the following:
did:key:<multibase-encoded-extended-public-key>;hd-path=m/44'/60'/0'/0
This would yield a did document with an ethereumAddress (/60 is ethereum, /0 is bitcoin)... you can see others here: https://github.com/satoshilabs/slips/blob/master/slip-0044.md
dmitrizagidulin
Wondering if there is way to use did:key to encode a root public key and an hd path...
This would let you use the same entropy source for many different did:keys... At resolve time, each did:key would be decoded, and then the hd path would be applied... bonus points if you can ask for ethereum or bitcoin addresses via the hd path... this would make did key a weird cousin of did:ethr and did:btcr...