Terminology discussion on derivation paths/accounts/wallets etc

[UkolovaOlga]

Discussion took place in the RGB telegram chat on Feb 4th, 2021.

@dr-orlovsky: A question for consideration: in my personal practice I started distinguishing three things regarding bitcoin keys & signatures

1. Extended master key (the root)

2. Specific “key accounts” - derivation paths used for different signer roles.
   The second option is usually called just “an account”, or “a wallet”, but this is not true - once you have a multisig or miniscript descriptor-based wallet there is no 1-to-1 match between them (“key accounts” and “coin accounts/wallets”) anymore. So you end up with.

3. Actual wallets, potentially using multiple of N2 and N2 used in many wallets.

I am struggling to find self-explanatory names to distinguish these two types/levels of “accounts”. “Wallet accounts” and “key accounts” seems to confuse that they are two types of accounts (but it’s actually two levels, one required for the other and one that can participate in the other)

@weedcoder: is it the difference between a basepoint and a pubkey?

@dr-orlovsky:
1 & 2 - yes. 2 & 3 (the actual question) - no
So (1) master extended key —1-to-many—> (2) account extended key <—many-to-many—> (3) wallet.
the question is about self-descripting names to use for distinguishing (2) and (3)

@johnsBeharry: is it correct to assume that in all cases an account would be used to derive payment requests (addresses)?

@dr-orlovsky: Correct.
Let’s take four-fold case:

1. I need one “wallet” for my day-to-day spendings
2. I have a company where I am a director signing payments (multisig)
3. I have some funds to HODL long-term with multisig between my family members
4. I need to distinguish RGB-enabled accounts from usual onces (otherwise I may use RGB funds if occasionally imported one of the accounts into a different wallet app not supporting RGB)

And I want to keep a single seed for all of them

With modern wallets this is impossible to configure. With my work on rust “descriptor-wallet” library it is. But I need more terms to define new, more wider use cases.

So,
A. The seed is the “master extended key account” (previously named “wallet” in multiple existing apps). I put the seed in a deep cold storage.

B. I use it to derive four “key accounts”, or “signing accounts” or “signer roles”, one per case. They are represented by an “account extended private/public keys” kept in hot storage (except 3, going cold)

C. With these roles I do four wallets, which track/sign actual transactions.
1) single-sig normal addresses: two derivation paths
2) multisig, i.e. I will use the other “signer role/key account” for this descriptor, but it will be a P2WSH one, with other keys and potentially time-locks involved; so the address will be created from multiple keys, many of which will not belong to my seed
3) multisig with the similar setup as above

• and For each of these three each wallet will use two different “key accounts” (RGB and non-RGB, aggregated for the end-user)

A, B, and C are named “wallets” by different apps, so this name is really confusing. And B and C are also “accounts” in some sense, but very distinct kinds of account. The end-user interaction happens with C, but the user must be avare B level (for instance as a director I can have several corporate accounts at level C sharing the same signing key from the level B.

@johnsBeharry: whats the derivation path for rgb accounts gonna look like?

@dr-orlovsky: m/84’/827166’/account-no’/0/*, or /1/* for change outputs - pre-Taproot

827166 are the decimal numbers for “RGB” letters

for a post-taproot world it will be something like m/340’/827166’/account-no’/0/*

@johnsBeharry: Ye the big problem is that all wallets don’t follow the bip44 multi account path m / 44' / 0' / 0' and sometimes shortening it to m/0' See http://walletsrecovery.org. So this leads to issues with interoperability. Descriptors are also an export format that can be generated for any level in that path.

Arman: As a user, I don't care about the nomenclature, I just want to know exactly the derivation path a software wallet uses so I can confidently replicate it a other software wallet should I ever choose. Many wallets do no divulge this info, and I see no reason they shouldn't.
I want full control, should I choose to exercise it.

@dr-orlovsky: that’s why I created Bitcoin Pro tool and will follow the same logic with MyCitadel wallet.

ig you will use bitcoins in your life - for savings, spendings & doing corp stuff - you will have no other option than get into derivation path details. Modern corp banking is much more complex actually. So, for many real-world use cases after wider adoption the solution “one key - one account/wallet” will not work at all and we need to distinguish it terminologically imo.
The fact that there are no wallets supporting it should not stop us from doing this distinction because (1) we're developing a wallet supporting all of this and (b) one day we will need to use this stuff for managing our own accounts (I already need it).

@johnsBeharry: I do think we need to design bitcoin applications as banks instead of just “wallets”.
I would love to see bluewallet with accounts for my one seed, it actually solves this problem partially already. Its so quick to create a new seed with it. I use them as accounts. After scanning an address, it asks me which wallet I’d like to pay from. The problem is backing up all those seeds.

@polto: BIP85?

@dr-orlovsky: Very good point. Actuallt goes in line with my thoughts on the matter. But makes terminological problem even more complicated 🙂

@polto: agree.

@dr-orlovsky: [answering Johns] that’s why I think there should be only a single deeply cold seed - and the rest is derived either with BIP32 or BIP85. The root seed should be never imported, only derived per-account extended private keys. And they will be used many-to-many for the actual address derivation.

@polto: careful with BIP32, non hardened derivations are not safe if you leak one of the child private keys.

@johnsBeharry: if anyones interested ive done some research on the use of a contacts list for separating utxos , that also has a component of output descriptors. https://www.dropbox.com/s/8a8wnafvagsupaj/payment-abstractions-demo.mov?dl=0
now it doesnt exactly address the naming problem though.

@giacomozucco: I'm still reading up beyond this point, so maybe this suggestion is either redundant al already rekt by some argument later in the chat...but what about "policy" for (3)?

@johnsBeharry: there is also discussions around dropping wallet and account and using “keyrings / keychains” instead. not sure if this is something that works for the masses though.

@dr-orlovsky: So, my proposal is to:

• don’t use “wallet” term in definig all these sorts of accounts, since “wallet” is overloaded and used in different way by existing software. “Wallet” can be an app, not something from N1-N3 above (see the original post I am replying to)

• the master seed is already named “seed” or “master key” and that’s enough for N1

• when we talk about N2, the extended (non-master) keys, we dont’ always mean “address” or oeprational account and rather a combination of a role & use case for the fund management (“this derivation path represents me as a CEO of my company”, “this derivation path is my path for the daily spendings”, “this path is for HODLing with family-wide multisig”). So I propose to use “signer role” term for it - or, alternatively, “keyring” (already used by me in github.com/pandoracore/keyring”)

• single or multiple signer roles are combned into deterministic creation of normal (non-extended) keys for composing addresses from descriptors. Let’s call this layer N3 “account layer”, since it actually represents the same concept as a “banking account”: “current account”, “savings account”, “corporate operational account”.

@giacomozucco:
Agree to avoid "wallet".
Agreed with "seed" for the master secret.
I would probably suggest "policy" for 3. Even if a policy could be more like an abstract blueprint of the "concept of 2of3 +1 or CVS"...non the actual implementation.

Not sure about (2). Role, account, identity. Maybe it IS an identity.

@dr-orlovsky: there is already “miniscript policy” which is a code generating actual miniscript code.

@giacomozucco: True...what is its relationship with (3) though?

@dr-orlovsky: and yes, (2) is an identity. And there is a RGB usecase for managing this identity - I will describe in a moment.

@dr-orlovsky: well, (3) can be defined by miniscript policy
(but can be defined without it as well, in a legacy way)

@giacomozucco: So it could make sense. It is a policy...which COULD be a miniscript policy, which is a particular kind of policy description? Confusing?

@dr-orlovsky: Let’s imaging a real-world user from the external world. Most of time it wil work with N3. will he understand why it is called a “policy”?
Imaging you have a real bank in your pocket as a mobile application, signing your transactions. What you need there? Right, “accounts” for different use cases. If they will be named “policies”, wouldn’t it confuse?

@giacomozucco: will he? or more with N2?
possible

@dr-orlovsky: N3 is the way to track balances & operation history
you can’t do that at N2

@giacomozucco: but a multi-party organization is usually not called "account"
account seems very "one person"
we DO have conjoint accounts in banks

@dr-orlovsky: “corporate account” with multisig from 3 directors - used in fiat corp banking

@giacomozucco: true
seed, identity, account
makes sense

@dr-orlovsky: very cool. and simple

@johnsBeharry: the account has a policy.

@dr-orlovsky: correct. which can be a miniscript policy

@johnsBeharry: you can export the account’s policy which will allow you to migrate to another app.

@giacomozucco: we just have to manage possible confusion with stuff like green where (so far) they call identities "accounts".
it's also interesting the case of joinmarket where particular identities are called "mixdepths"

@dr-orlovsky: this is how such terminology will look like for example

@giacomozucco: yes. not obvious
but I don't have good alternatives in mind
maybe you could do it let flat
like: the identity is selectable with an avatar on the top-right corner, much like accounts today are with google when you use gmail, or with telegram, or github.

@johnsBeharry: the identity changes which accounts are available for spending

@giacomozucco: Exactly. I would probaly have the identity change in the same way we have it on social or messaging apps (where they are called "accounts")....and when you select one, then you will see different ....things (which we are now calling "accounts")

(now I remember: this would be the reason I think "account" could be confusing...not really for bank account, which are often shared/joint...but for typical platform/social accounts)

@dr-orlovsky: is there a better name/synonym for a bank account?
we can have “financial accounts” and “signer identities” 😄

@giacomozucco: I don't think so. But the fact that many many mass products used "account" for identity may create confusion. :/

@johnsBeharry: i think account is fine — its a fintech app. more abstractions will lead to more ambiguity.

@perrysmith: funds

@giacomozucco: Probably in github, our identity would be an "account", while our account would be an "organization"😂

Wait..."contract"?
Could make sense?
Unfamiliar but not ambiguous
a bit ethereum-like unfortunately
but that's the concept

@dr-orlovsky: and there are “asset contracts” in RGB already 🙁

@giacomozucco: indeed, an organization IS a contract

@dr-orlovsky: but still “contact” may work

@giacomozucco: a bank account is a contract
we could avoid both account and wallet....seed, identity, contract

@dr-orlovsky: agree

@giacomozucco: and we will explain in some wizard that account and wallet are usually used for our identities (google, telegram, github) or our contracts (bank accounts)
but then we should distinguish better asset contracts

@dr-orlovsky: and there are different forms of contracts - saving, current, “staking”, instant payment contract (lightning) etc

@giacomozucco: which can be just "assets"

@dr-orlovsky: right
and contract has a policy (spending policy)
made of different identitites (for multisig policies) + other conditions

@perrysmith: Synonyms contracts: agreement

@giacomozucco: Interesting discussion btw. a rabbit hole of stuff I never rationally considered ahaha.

@dr-orlovsky: me too before I tried to do a wallet for my own needs
and unrwap all that I need to do with fiunds, bitcoins, assets into a structured system

@giacomozucco: an individual, which is not represented in the software, can access the software with one or more seeds (1tomany), each of the seeds can expose one or many identities to the world (1tomany), and each identity can enter in different contracts with other identities (manytomany). each contract can have many assets (1tomany) and, separate, many invoices (1tomany)
yeah, it's a mess 😂
probably we can make some default assumptions for simple use cases.
but not really, since for example non having multiple identities as default creates strong privacy concerns (indeed coinjoin wallets will default to 5 or more).

@dr-orlovsky: exactly what I ended up myself when thought for that for a long time; I just needed terms for these and I am happy with what you proposed

@perrysmith: Let users be able to rename the categories?

@giacomozucco: Flexible but messy: you disrupt tutorials, faqs, Q&A online

@UkolovaOlga: definitely not from day 1. it indeed will require too many resources on ‘support’ and on managing/mitigating misunderstandings.

@perrysmith: I understand and agree

@giacomozucco: wait...invoices instead of addresses

@dr-orlovsky: already in LNPBP-39 and RGB. Address will be just one of the options for the invoice internals
we have a plenty of simple wallets for “normal users”; I think it’s time for something for more “power users"

@weedcoder: cold precious entropy > paths > wallets.

@dr-orlovsky: technically speaking - yes
but will be vey ambiguous/confusing for end-users
cold precious 1=>∞ paths ∞<=>∞ wallets.

@giacomozucco: agreed.
The word entropy is pretty triggering to me: it already represents basically EVERYTHING in physics, from the quantity of thermodynamical heat (caloric fluid) in a body to the volume of the phase space in rational mechanics, to the information necessary to describe a microstate, to the area of an event horizon, to the euclidean action under wick rotation, ahahah.

@UkolovaOlga: there are ‘profiles’ also

@dr-orlovsky: if we’d like to avoid confusion with “identities”, I think “keyring” may also work

@weedcoder: i see them as responsabilites
role assignation or attribution
or just signatures

@perrysmith: signatures. yess. signet.

@dr-orlovsky: so, about using RGB for managing this specific form of identitites (signing key-based identities). Why it is a good case?

With derivation we have a situation when the key backing some contract has leaked and we need not to use it anymore - and need to use a different derivation path for the future use in the same role. Let’s say in 3-of-5 corp multisig one extended pub key leaked. The role/identity does not change (I need to act as a copr director with signature), but the derivation path should. So if we use something like m/…/identity’/0’/0/* for that identity, we may switch on m/…/identity’/1’/0/* for it, without changing identity name etc - just marking the previous path as “revoked”.

This works well for a single-user single-device case, but in the rest of cases how to coordinate revocation across devices & other directors (and avoid fishing etc)? And also creating a verifyable (but anonymous) corporate log? With RGB identity smart contract!

@giacomozucco: The problem in my view is that keyring would be more like the seed...which already has a good name
or with the part of the sofware currently keeping the keys, which is often called "wallet"
lol
You don't communicate to the extern the keyring you are using to access

@dr-orlovsky: right.
another important case for use of RGB in this context is that with RGB you may prove relation between two distinct identities w/o revealing any of the extended public key information on the paths upstream in hierarchy

@polto: I wanted to have something similar and was thinking of having a ZK proof of derivation from the same seed.. but never seen anything like that yet.

@St333p: Sorry if I jump in late to the discussion,
What about, since we started from plant-related terminology:
seed / root / branch?