Changing crypto-account to crypto-keyset?

[ChristopherA]

In regards to UR Type Definition for BIP44 Accounts…

As we work on the user-interface for our dedicated multsig co-signer app this week, we are running into a namespace collision / user confusion with calling this a crypto-account. It is only an "account" when it is used as a single-sig descriptor, but when it is used in a multsig it isn't really a full account but something else.

Instead, I'd like to call this crypto-keyset, as keyset is the term used in a variety of cryptographic protocols for groups of associated keys. Then it is clearly differentiated from things like an Account Map, which has one or more keysets in it.

Is it too late to make this change?

/cc @craigraw @wolfmcnally @Fonta1n3

-- Christopher Allen

[craigraw]

The crypto-account was of course a reference to a BIP44 account. While I'm not completely averse to making this change, the definition for Account Maps is the only place I've seen a wallet called an account, whereas the BIP44 definition of an account is I think well accepted now. A keyset has a less specific definition.

Should Account Maps not be called Wallet Maps? I was certainly confused by the former when I first heard it, and I think it might be easier for users, who might consider their 'Bitcoin Wallet' to be described by a 'Wallet Map'.

[ChristopherA]

In our research we have found that the legacy of calling a singlesig bitcoin HD derivation a "wallet" causes problems for both developers and users.

It worked fine in the days of one bitcoin app / one seed / one derivation (e.g. Bread Wallet), but began to break down when hardware wallets started having multiple sub-accounts, and now is worse with legacy, wrapped, segwit-native, and multisign. Finally all of the above are "single-seed" but Gordian and other modern wallets also supporting many seeds.

Thus I've strongly encouraging calling anything that derives a linear series of keys available for UTXOs an "account" not a wallet. Thus an "Account Map" is a descriptor with only XPUBs in it that describes that linear series. Since "Account Maps" can have 1 or more xpubs (plus fingerprint & path) in them, calling those "accounts" is a name space collision.

-- Christopher Allen

[craigraw]

I understand your point, although I don't think we can get away from the semantic meaning of a BIP44 account either - for example the Coldcard uses the word account in the BIP44 context - see the 'Multiple Accounts' section here. Perhaps we need another word!

That aside, I'm still trying to understand the original issue. In my understanding the user never sees the phrase crypto-account - they just see the QR code. It's really just an identifier for developers to interpret the UR bytes correctly. From that point of view, it seems we are free to use the term that describes the data best since users won't see it.

[ChristopherA]

These developer words creep ino our UX. I’d like to nip this confusion now and encourage the use of word keyset for this. It is just more accurate.

[craigraw]

The problem I have is that I don't think it is - keyset could describe any set of keys, while account describes the specific set of keys that relate a particular BIP44 account. And I think the use of the word 'account' is too widespread in this (BIP44) context to change it now, and therefore its overloading with Account Maps risks replicating some of the same confusion we already have with the use of 'wallet'.

That said, happy to make this change if there is consensus on it. @wolfmcnally @Fonta1n3

[Fonta1n3]

It may make sense to differentiate between single sig accounts and multi-sig accounts. crypto-account includes an array of single sig and multi-sig account based descriptors. However for multi-sig you would obviously need other parties crypto-accounts to actually form a complete output descriptor.

The real core issue here is when creating collaborative multisig wallets we need a common name for the thing a user needs to export/import to create a multisig wallet with other parties. As far as the logic/code is concerned the UR type crypto-account works perfectly for that purpose and I have no issue with its naming as it is indeed composed of accounts and it is meant for devs not users.

However as far as UI is concerned Sparrow and Electrum use the term keystore, I do think keyset or keystore are better terms for this single item which only represents public keys and is not a complete output descriptor: [00000000/48h/0h/0h/2h]xpub61.....

An output descriptor's purpose is to unambiguously derive scripts/addresses (generally speaking) not just public/private keys. The above example does not specify a script type whereas a descriptor does.

I am not sure Account Maps are entirely relevant here. An Account Map is a json dict which specifies the blockheight where the wallet's first transaction occurred, the user specified label for the wallet and the descriptor (bitcoin core output descriptor) used to derive addresses for the wallet. The reason it is called an Account Map is because generally the output descriptor describes an account (as per BIP44/84/49).

crypto-account is an array of account based output descriptors. To me account is the accurate term to use which also happens to be widely recognized and adheres to well established standards (bip44/84/49). The description for bip44 is after all Multi-Account Hierarchy for Deterministic Wallets.

It is worth noting there is already a UR type for cose-keyset which describes a set of encryption keys which certainly does seem to fit that purpose.

@craigraw the reason keyset came about was because we started using the term keystore (just as Sparrow) in the UI to describe the individual xpubs with origin info to export to a collaborative multi-sig wallet such as Sparrow or Gordian. @ChristopherA thought keystore was confusing so we opted for keyset.

Really what we need is an actual BIP for the 48 derivation and common terms for the UI to describe an incomplete multi-sig output descriptor (@ChristopherA came up with Policy Map) and to settle on the name for the individual keystore / keyset items.

[Fonta1n3]

I think we should probably drop keyset and keystore in the UI altogether and simply refer to them as cosigners as that is really what they are and what most other apps/wallets refer to them as. It is also easy to comprehend. Perhaps a new UR type crypto-cosigner would be appropriate for multisig accounts which do not represent a complete output descriptor.

[ChristopherA]

I'm fine with crypto-cosigner if you don't like crypto-keyset. What I'm very strongly against is calling it an account. After my 5th zoom call where devs and UX people were getting confused on keys that sign multisigs versus the account that has balances, we need this separation of terminology.

@craigraw Can I get you to either +1 to crypto-keyset or +1 to crypto-cosigner? I am -1 crypto-account.

@wolfmcnally, do you have an opinion?

[craigraw]

Re crypto-cosigner, I think what @Fonta1n3 meant was a new UR type for a different purpose. Because crypto-account also contains single sig details, the word cosigner wouldn't be appropriate. On that point, a clarification - I considered splitting out the multisig output descriptors, but ultimately you can build a cleaner and simpler UI if you don't require the user to choose, and there is no downside I can see.

I think the arguments above still stand, but I want to avoid being dogmatic on this. How about crypto-keystore? It is a bit more specific than keyset, and better than some version of signer since we do more than just transaction signing with these details.

[craigraw]

Following up on the above - any objections with crypto-keystore? @ChristopherA

[ChristopherA]

My problem with keystore is that people think that stores keys. A keystore to the non-blockchain devs I’ve spoken too is a secure hardware API to store keys, like Apple’s keychain. Some IETF standard document refer to “required that a system has an operating system level keystore utility to implement this”.

keyset is what IETF standards use to call lists of keys. For instance RFC 7517 Appendix A.

Which is precisely what this is: a description of how derive a set of keys.

[ChristopherA]

BTW, among my other goals is to drive URs to be used more broadly than just in the bitcoin community, but also in standards communities like IETF & W3C. A keyset is also useful for emerging privacy standards like whisper protocol, DIDs, FIDO, etc.

[craigraw]

Thanks for the info @ChristopherA.

A keyset is also useful for emerging privacy standards like whisper protocol, DIDs, FIDO, etc.

This highlights exactly my original concern - that keyset is generic and useful in a variety of contexts. But perhaps you can clarify your vision here - how do you see these keysets as part of the UR standard? For example, do you see a crypto-keyset as currently defined, and further whisper-keyset, did-keyset, fido-keyset formats? Or do you see these fitting into BCR-2020-015 somehow in future?

If we can understand the path forward, I think we can agree and resolve this.

[ChristopherA]

(Maintainer note: I've converted this from being an issue in Research to a Airgapped community thread in order to have a broader discussion of requirements.) /cc @craigraw @Fonta1n3 @wolfmcnally

[ChristopherA]

I wondering if part of the problem of closing this topic is that we didn't fully state the use cases / developer problems that the bcr-2020-015 - UR Type Definition for BIP44 Accounts proposal was to address.

The original goal was to address how to describe in CBOR a singlesig BIP44 bitcoin "account" path, and the choice of selecting paths 44 (legacy), 48 (nested segwit) and 84 (native segwit). derivation.

This proposal also suggested that this could be used for bip45 and the so-called "BIP48 Multisig", which is not a BIP and is underspecified, that supports all three (legacy, nested segwit, and native segwith) as sub-paths of 48'. See the discussion at We Need to Document Bitcoin HD Derivations for Multisig (aka m/48' or BIP-0048) on problems with the 48'.

However, an important related use of this emerged which was to enable requests and sharing of a single xpub, such that a multisig descriptor could be created. We need this CBOR to allow for URs for transaction coordinators (e.g. Unchained's Caravan, Casa, River, etc.) to request a master-key fingerprint, path, and xpub, in order to add it to an Account Map (a descriptor with only xpubs, plus some metadata, see #6)

So these two requirements have become conflated, causing some confusion. There also is some ongoing confusion in the bitcoin developer community in use of the words like "wallet" and "account", which unfortunately have migrated from developer words into user definitions. (IMHO, an account is only an account if it can have a balance, and a wallet is an app that contains accounts, other keys, and metadata).

A solution here might be to redo this proposal. First we specify what bitcoin core calls a "key expression" (i.e. [masterfingerprint/path/to/newroot]xpub… e.g. [d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*) as a crypto-keyset CBOR, then we build on that CBOR to describe a simple single-sig account descriptor CBOR, as well as the more complex Account Map (descriptors with metadata).

@craigraw Does this accurately describe our dilemma?

[Fonta1n3]

(IMHO, an account is only an account if it can have a balance, and a wallet is an app that contains accounts, other keys, and metadata).

I think this is the source of confusion and disagreement. For crypto-account the entire purpose is to define the account derivation as per BIP44/49/84 specification. Which is why we opted to use the term crypto-account.

I think you have accurately described the confusion and the fact that another ur type (keyset/keystore/cosigner) should be created for multi-sig key sharing purposes.

I would bring up that there already is a keyset UR type so we need to be careful about causing confusion between the two.

[craigraw]

I think you have accurately described the confusion and the fact that another ur type (keyset/keystore/cosigner) should be created for multi-sig key sharing purposes.

Agreed with all your other comments, but not this one - please see my response below.

[Fonta1n3]

Yep, only suggesting that as a possible middle ground here... As is, it serves its purpose well imo.

[craigraw]

@craigraw Does this accurately describe our dilemma?

No, I don't think it does unfortunately.

(IMHO, an account is only an account if it can have a balance, and a wallet is an app that contains accounts, other keys, and metadata).

I understand your point of view, but as I've said before we are not going to change the BIP44 meaning of account. (Or, respectfully IMO, the widespread use of the word 'wallet' in just about all Bitcoin software to define what you have called account). That said, it's not really relevant to this discussion - I'm happy to find a less controversial word than account, I just want to make sure that we don't choose one that is too generic and causes confusion in future with other valid 'sets of keys'.

To restate the purpose of BCR-2020-015: It allows hardware wallet (or 'keystore') developers to have a single and standardized way of sharing the public key information about those keys. Currently, sharing this information requires not only selecting whether you have a singlesig or multisig setup, but also the script/address type. This is confusing for users, and completely unnecessary, since the wallet co-ordinator software (which generally has a much more capable interface) already knows this information.

To make this even more clear: A hardware wallet developer need only implement two functions. One shows the crypto-account QR code. The other initiates signing using crypto-psbt. IMO we should prioritise this essential user experience, and there's no need to make it more complex for this essential functionality.

[Rspigler]

This is my understanding:

An "Account Map" is an xpub only descriptor. It will be sent by the coordinator back to the signers. It maps back to the BIP44/84etc account.

crypto-account offers an array of all script types to supply to the coordinator, for the coordinator to choose the necessary descriptor (the signer can initiate the multisig creation with this, or the coordinator can initiate with a request to join via an empty descriptor - a "Policy Map"). If we are renaming the crypto-account due to the collision, think it is best to refer to this as crypto-cosigner like @Fonta1n3 suggested, as it is an array of account-based descriptors of the cosigner. I think this helps with the UI too. Not a big fan of keyset.

I don't understand @craigraw 's issue of when you'd use crypto-account/cosigner in a singlesig scenario. Maybe we need to split the issue up like @ChristopherA suggested (1- how to describe/select a singlesig BIP44 account path, and 2 - how to request/share an xpub to create a multisig descriptor)

[hansbkk]

I acknowledge I am a noob, even a rube, way in over my paygrade, but sometimes that POV can be useful to those living deep in the weeds. I am limiting this to BIP compatible HD contexts, obviously nothing here is new to y'all, and I'm not even suggesting terms here, just giving examples for clarification of my understanding.

These terminology issues were a major frustration for me, even a barrier to learning in my first 500 hours. I have adopted "Account-Wallet" to mean all the nodes/ keys/ addresses/ scripts collected under a given BIP39 seed, BIP32 root / master extended key. Not necessarily as defined by any given Wallet-Client implementation, just the 'conceptual collection' living on the blockchain.

Of course these nodes are "random", observers need a secret master key to even know these nodes are correlated to that account-wallet.

Accounts themselves are sub-trees within the overall account-wallet. Many wallet-clients limit themselves to importing only a single account / derivation path e.g. Electrum's dev is very passionate on that issue.

Other wallet-clients allow for convenient access to multiple accounts within one UX without switching.

Do any allow the same across multiple account-wallets at the seed level? Or at least easy but still secure switching between them?

So, everything above is single-sig. I have not yet begun to grok multisig yet, so this may have been useless, if so feel free to delete it, all I got for now.

[craigraw]

Most HD wallet software I know of think of an "account" as defined by BIP32, which defines HD wallet specifications.

[ChristopherA]

@hansbkk I appreciate that your comments.

I am concerned about the terminology collisions in bitcoin with overloaded use of terms wallet and account. I think it causes many headaches for users, and a learning curve for Bitcoin developers. These, plus a few other terms also doesn't quite match terminology from outside Bitcoin, for instance for Ethereum-family applications and digital identity tools.

So far we've had to back down from a number of the changes I'd like to see (like keyset) because at this time our most active sponsors and implementors of our proposals are bitcoin app developers, and they like the language that exists now. As more companies use these emerging standards, hopefully we can update them in the future for more consistent terminology.

[hansbkk]

Thank you.

[wolfmcnally]

The Decentralized Identifiers specification refers to structures that contain or can be used to derive many flavors of keys as a "base" as in publicKeyBase58 or publicKeyMultibase. I have started to adopt this terminology on my work on the Blockchain Commons Secure Components Suite.