I’ve had this one in drafts for, checks notes, more than 3 years! And I thought it made sense to just push it out. Make sure it is known to the world, no matter if people want to use it or not.
So this is a document that uses the concepts of HD wallets. Masterkeys and derivations. It explains various neat things you can do with them and a standard numbering for those new ideas as I imagined or even use them today.
Please have fun, and maybe we can extend this with other known derivation path innovations people use today?
I recently made a pull request for Electron-Cash (pending review) using the keys at m/44'/145'/0'/2/0 and m/44'/145'/0'/2/1 for RPA, but apparently it’s already used according to your CHIP and I will update my branch to something else.
Initially I used the keys below the path m/44'/145'/0'/8 because that was one higher than …/7 which is promoted by the WizardConnect documentation for DeFi: Wallet integration - Riften
This shows that a registry of known paths that the community can gather around is needed and this CHIP could be the start of it.
I also am imminently publishing an RPA library for TypeScript and was planning to use m/44'/145'/0'/2/0 and m/44'/145'/0'/2/1 for RPA.
However, upon reading Tom’s CHIP draft, I do not think this usage is incompatible with Tom’s usage of this path for “wallet identification.”
If the intent is beyond identification of the wallet itself, such as some user account scheme, I would personally use m/44'/145'/N', where each path N is a single account, with the existing 0' path simply being a “default account.”
My thoughts were that 0 is the wallet itself in a way that you use it for store/restore. You’d use it to find the comments on all your old transactions.
It doesn’t specifically seems a problem as RPA itself doesn’t really announce the pubkey or its address AFAIK. But it does beg the question how many RPA’s you want to publish. Why not an infinite amount?
And you can cleanly mix it with logins for websites. All on the same derivation. Just don’t reuse addresses
The zero is a bit special since you JUST have a seed at the time you derive that one. No backup is restored yet. You get the backup from that zero’th key. Hence the reservation.
After you restore the wallet with that zeroth, your metadata can indicate which index was used for what.
My suggestion is to just start with 1 on your library. Probably allowing the user to select any N in m/44'/145'/0'/2/N where N is larger than 0.
This mirrors the CHIP. So, sounds good.
After the BASE (2 levels) we add a 3rd level we call the extension . The extension defines multiple actual physical wallets being used from the same seed and the same base.
The paycode itself, that the user publishes openly, does contain 2 pubkeys.
Theoretically a user could create an infinite number of RPAs.
I propose:
RPA #1: m/44'/145'/0'/X/0 and m/44'/145'/0'/X/1
RPA #2: m/44'/145'/0'/X/2 and m/44'/145'/0'/X/3
RPA #3: m/44'/145'/0'/X/4 and m/44'/145'/0'/X/5
And so on.
I think X=2 should be avoided if there is any known usage. I used X=8 in my pull request for Electron-Cash, but I can certainly change it to something else. What do you think @kzKallisti ?
In practice I think most users will only publish 1 RPA/wallet and I think most wallets will only allow that for the foreseeable future, but flexibility is needed.
I was suggesting m/44'/145'/0'/2/1 and m/44'/145'/0'/2/2 in your setup, with 3+4 maybe for the next.
The idea is to avoid hard coding them and just like with the main and the change chains, you just keep increasing the number as the user requests a new ‘thing’. Where the 2 chain is labeled as “ownership” that works for logins as well as for RPA in my own humble opinion.
So if you have a website that you reserve an index for, you skip that one. Giving the next two after that for your next RPA. All inside of the BASE/EXTENSION/2/* list of addresses.
I agree with this. We can have “infinite RPAs” for a single “account” (as defined earlier in this thread) simply by deriving more keys from the /2 path.
From a UX perspective, this would likely represent individual logins for the same “identity” - e.g. if my /0 “default account” is named “Kallisti”, then I can have a separate RPA for each service I log into under the “Kallisti” account. If I want a new account/alias, I will derive from the previously-unused /1 path, which can derive its own RPAs under /1/2/0+1, /1/2/2+3, etc.
@tom - I want to make sure I understand your concern correctly. The main problem is if the RPA pubkey is exposed, right? And if I understand your backup system, technically we would consider the 0th key to be “exposed” as it was written to backup, right?
Does it make sense to instead use the hardened m'/44'/145'/0' path to identify an entire wallet (including all of its derived accounts/identities)?
I don’t necessarily oppose simply moving RPA up by 1 index. It’s just quirky
Semantically, though, I feel like /2 makes the most sense. Would be nice to be able to have it, but it’s not worth extensively bikeshedding over either.
The backup can be publicly stored on a server, under the address resulting from the zero.
As such, the publishing of the address for the same wallet, for instance for RPA, binds it to an encrypted backup file. I don’t specifically forsee that being a huge deal, but there is no reason to take any risk when addresses are practically free.
Maybe the word ‘identify’ is not clear. As the technical wallet already uses the path you pasted. It appends things like the change chain etc.
This is not the identity I was referring to.
The wallet identity is one bitcoin address that can be used to refer to the wallet. As opposed to referring to reddit.com (as in, a login key) or another public key that is the login for this site, bccr com.
The choice of 2/0 (appended to that pasted path of yours) is simply to pick an address that is unused by any payments or other things. So thigns stay private and nobody will be able to find that comment-backup file and tie it to you.
It is a simple avoidance of reusing an address.
I mean, my point of view is to not see it as “moving it up one index”. The point I’m trying to support is that the /2/* chain is for a lot of keys. And you want to avoid reusing of keys.
So it becomes needed to reserve keys in your wallet. If you implement the feature to do logins on websites then you reserve keys for that. And if the user just happens to create an RPA at a later date, it just uses the first free one.
So no different than main or change addresses where you avoid reuse.
And I agree, please use /2/*
It falls in the concept of the CHIP, I have no problem with it.
Just the basic request to consider the /2/0 key pre-reserved. If you don’t, then I won’t lose any sleep over it. Some users may complain and if you want to do backups in your wallet at a later time you’ll be forced to do is incompatible with mine, which is why I’m writing here.
If I am reading this correctly this would mean that it would be hard to move a seed between wallets with different functionality. Wallet A (that supports “identity” but not RPA) could use m'/44'/145'/0'/2/0 as a login to a specific website. If a user enters the seed into Wallet B (that supports RPA but not “identity”) a paycode would expose the pubkeys m'/44'/145'/0'/2/0 and m'/44'/145'/0'/2/1 and anyone with knowledge of the identity and paycode would be able to link the two to the same user.
Therefor RPA should not be derived on a path that is known to be used for anything else so any RPA capable wallet could recover funds from the known path.
@kzKallisti So “up 1 index” and use m'/44'/145'/0'/3/x for RPA seems appropriate.
To tie it al into a nice ribbon; the /2/0 key is used to do the comments-backup I mentioned? This can naturally also be used to backup your other details, like which identity matches which key. So restoring from seed also restores all this info from a (cloud based) backup.
