Requirements for a cross-wallet "Account Map" with xpubs

[ChristopherA]

We have been working on an "Account Map" with xpubs, wallet descriptors, and other metadata for fully restoring a multisig account.

Though these can and should be able to be saved to disk, we imagine these as being printed on a QR code to accompany each seed that is backed up for that account — the scenario being you only need one of these papers to survive a fire or other tragedy and the quorum of seeds, and that the compromise of which only hurts your privacy, not your access to funds. Also, if a single seed is used with multiple multisig accounts, you only need to add this paper to your storage location, not re-archive the seed.

@peter-conalgo has shared a similar fomatted document in JSON in the most recent firmware of @Coldcard https://github.com/Coldcard/firmware/tree/master/docs/generic-wallet-export.md

My only reservation with this is that like some of the earlier proposals in this repo, using JSON may make it too large to print on a single QR code.

-- Christopher Allen

[ChristopherA]

@Fonta1n3 — can you share here an example of our latest Account Map prototype for Fully Node 2?

-- Christopher Allen

[Fonta1n3]

and the text:

{"birthdate":1587962035,"blockheight":1,"descriptor":"wsh(sortedmulti(2,[82be8e74\/48'\/1'\/0'\/2']tpubDEYij9WndcWU4ApaSz68RitBMrZRTfShsXn4qw1izEaFScR5dnP4dz1CzgmfT5iTrNeZJhMXieg2BzhCFNxrWtvaTerBio3VbFoSDixs4yR\/0\/*,[5222e39c\/48'\/1'\/0'\/2']tpubDEQznV4Xs6BP1A1HXzogRsUiFxDsyaqLzphZmjmwrrERz9aHszb2juQzYBx9xuXymba5kkQvR76m218JiXM1DsLcgPryGCDs5P1geHoxVrx\/0\/*,[81202613\/48'\/1'\/0'\/2']tpubDEcrpYzpqTJyhy5bzsojvL8VMrcFf4DVU7q43fuq6JhhNyxCqLzhppiUsMHAXUJv4XTnmAiezNAzdfTdg2FFefbzNh8YzN6Wv2zEYwcCC22\/0\/*))#czsstq8d","label":"2 of 3"}

[Fonta1n3]

For the privacy conscious an improvement could be a 2/4 or 3/5 where you save less then n xpubs with each seed, ensuring the seed also makes it less than n.

For example 2 alternate xpubs with each seed so that even if an attacker found one seed with a partial account map you would not lose privacy.

With a 2/3 you could save one and a half xpubs with each seed.

Thanks to BIP67 the order of the xpubs doesn’t matter making this method simpler.

[bitcoinhodler]

If an attacker has even one xpub (and derivation path) they can observe all p2sh or p2wsh withdrawals since the pubkeys are in the redeem scripts.

I opened #37 to discuss this privacy issue.

[aaronisme]

quick question here, the birthdate, and blockheight are really needed to account ?

[Fonta1n3]

quick question here, the birthdate, and blockheight are really needed to account ?

No, it’s just convenient for restoring by automatically scanning the blockchain from a specific date.

Actually we ought to remove the birthdate altogether and only keep the blockheight.

[stepansnigirev]

@Fonta1n3
In this QR code I see that you only have receiving descriptor. What about the change one? Should the wallet derive change descriptor automatically somehow? If so, what happens when descriptor is defined with the non-hardened path not xpub/0/* but xpub/* or xpub/28/* ?

[Fonta1n3]

@Fonta1n3

In this QR code I see that you only have receiving descriptor. What about the change one? Should the wallet derive change descriptor automatically somehow? If so, what happens when descriptor is defined with the non-hardened path not xpub/0/* but xpub/* or xpub/28/* ?

The wallet should automatically derive the change descriptor. We have just been adhering to BIP44/49/84/48 so that it is clear. Not sure how to handle change if a user imports a non standard account.

For FullyNoded we just replace /0/* with /1/* to create a change descriptor, removing the original checksum.

With Specter we know how you guys handle it so it’s easy to adapt. However there is an infinite number of paths a user could potentially come up with. If it is custom i feel it should just be imported as is without being manipulated.

Do you have thoughts or guidelines on this?

[ChristopherA]

Though I prefer defining a new change type 2 for mixers, I could see people pushing all change to the custody of their mixer wallet with a different xpub.

— Christopher Allen

[ChristopherA]

I think a user label is important. Users may use one seed with multiple multisig accounts (especially given effort to put in titanium or steel). The will need to distinguish them.

— Christopher Allen

[ChristopherA]

Currently we are sharing these as Javascript objects, but we may want to move to it being an UR specification.

See related discussions:

• We Need to Document Bitcoin HD Derivations for Multisig (aka m/48' or BIP-0048)
• UR Type Definition for BIP44 Accounts
• Changing crypto-account to crypto-keyset?

[Rspigler]

At Yeti, we have been very interested in creating a partial Account Map (we have been calling it a partial descriptor). We have had some thoughts and I will point our developers here for collaboration.

[bitcoinhodler]

By "partial account map" are you referring to the blob created by a key generation process, which is then communicated to the online node? It would include e.g. the xpub.

[Rspigler]

I was referring to some sort of proposal that would enable distributing trust with the descriptor like one can do with signatures. We were trying to do this without SSS, but your proposal was better than what we were working with

[bitcoinhodler]

Could/should we define a standard way to include BIP39 passwords in the account map? Motivation is explained in #37.

{
  "birthdate":1587962035,
  "blockheight":1,
  "descriptor":"wsh(sortedmulti(2,[82be8e74\/48'\/1'\/0'\/2']tpubDEYij9WndcWU4ApaSz68RitBMrZRTfShsXn4qw1izEaFScR5dnP4dz1CzgmfT5iTrNeZJhMXieg2BzhCFNxrWtvaTerBio3VbFoSDixs4yR\/0\/*,[5222e39c\/48'\/1'\/0'\/2']tpubDEQznV4Xs6BP1A1HXzogRsUiFxDsyaqLzphZmjmwrrERz9aHszb2juQzYBx9xuXymba5kkQvR76m218JiXM1DsLcgPryGCDs5P1geHoxVrx\/0\/*,[81202613\/48'\/1'\/0'\/2']tpubDEcrpYzpqTJyhy5bzsojvL8VMrcFf4DVU7q43fuq6JhhNyxCqLzhppiUsMHAXUJv4XTnmAiezNAzdfTdg2FFefbzNh8YzN6Wv2zEYwcCC22\/0\/*))#czsstq8d",
  "label":"2 of 3",
  "passwords": [
    "foobar123",
    "monkey456",
    "spaceballs12345"
  ]
}

Where the order of the passwords is the same as the order of the xpubs in the descriptor.

[ChristopherA]

Let’s not put seed words or raw entropy in this. Just a specific backup of the derived key & essential metadata to words. I suggest UR and bytewords so we can also do Shamir sskr words as well.

/cc @wolfmcnally

[Rspigler]

Account Maps are xpub-only descriptors, which the coordinator/online node generates. You wouldn't want BIP39 passwords in the Account Map.

[bitcoinhodler]

If the BIP39 passwords are being used for privacy from nosy signatories as I explain in #37, why wouldn't you want them in the account map? The user never needs to see these. The only purpose of the BIP39 password (in this use model) is so that someone with one seed phrase cannot derive the corresponding xpub and locate all my withdrawals in the blockchain.

Would this introduce some new vulnerability or attack vector versus using no BIP39 passwords?

[Rspigler]

Why use BIP39 and then shard the account map, why not just shard the account map?

[bitcoinhodler]

@Rspigler this is explained in the second bullet under Requirements in #37

[Rspigler]

Sorry, I'll comment there 👍

[ChristopherA]

Account Maps are xpub-only descriptors

Not precisely accurate. At minimum an Account Map is a Bitcoin Core wallet descriptor, where any keys use their public key version, which ideally are fully described (i.e. [m0fingerprint/path/to/0]xpub...). But it also includes other information such as the type of script and other information. In addition, the Blockchain Common' Account Map data structure allows for other metadata information to be included, such as birthdate of the account (when it was first used), account label, etc.

The ideal is that you can strip the excess metadata information, you can use an Account Map directly with Bitcoin Core 0.21.0+ for a new watch-only wallet.

[Rspigler]

Yes, descriptors include the script type. I don't mean 'just the xpubs', but rather a key expression and /xpub only/ keys in the descriptor.