Should we mention backing up the master xpub? #65
Replies: 2 comments 12 replies
-
|
The master xpub should be stored inside a descriptor (which gives all the necessary information to scan for coins), and descriptors already have a BCH code checksum on them. So we don't need to use codex32 for this. But I am certainly open to adding text somewhere recommending that people store their descriptors somewhere, and explain that there is a privacy but not a key-loss risk, so they should probably be more liberal in making copies than they would for their seed data. |
Beta Was this translation helpful? Give feedback.
-
Yes :).
Well, using hardened derivations will prevent this case. As well as the case where "recent" transactions are detected, or any transactions. I guess you would like a fully-derived descriptor, which could be used for watch-only purposes, but which also does not require electronic computers to obtain from secret data, and which also is stored using SSS. This does sound plausible, and I'd be happy to provide some pointers or basic support for such people, but I think for the vast majority of users (including myself) it's likely to do more harm than good.
They can't get an open warrant for all gpg-encrypted data. There would have to be some clear indication that the encrypted data was an actual descriptor. (Or maybe we are in a mad max world with no warrants or due process.) |
Beta Was this translation helpful? Give feedback.
-
By this you mean redacting your own child extended public key from a multisig descriptor? I think this depends on script type, OP_CHECKMULTISIG puts signer public keys on blockchain, linking recent spends (but not deposits) if scanning the blockchain. The new taproot multi_a type would make this perfectly private. That sounds easy enough to do and hard enough to screw up, especially when codex32 IDs match the descriptor's key origin information fingerprint for the redacted xpub. (This ends up being useful so often, for so many things (even the CodexQR benefits), it should be the Recommended ID if no strong reason exists to change it.) It also forms a sort of threshold 2 "secret sharing" between two co-signers (who both redacted their own child xpub but not others) where combining two has enough information to watch the wallet without putting private keys on electronics again. This is quite slick, would you recommend it? Private keys touch electronics to restore descriptor by yourself, two co-signers required to restore descriptor without private keys on electronics. Only works with multi_a() scripts. Only draw back seems to be co-signers can't store the descriptor in a public location and get strong privacy. The way I'd get around that is also encrypt the descriptor to each co-signer. BIP85 has a standard for recovering RSA keys from a BIP32 root key. That creates an encrypted descriptor that can be stored anywhere and redacted copies that need to be stored with some security and in different locations from your co-signers' redacted copies. If people keep a passphrase encrypted backup of their RSA private key, they can watch restore without bitcoin private keys on electronics. If the RSA key is lost, it can be restored from the codex32 secret. You might deliberately lose it in a mad max scenario to make watching require compromising multiple locations and/or people not just a passphrase. |
Beta Was this translation helpful? Give feedback.
-
Yes, I think this is fine, because it's a "public 2-of-2" but "private 1-of-2", in the sense that either party could get the full descriptor back, as long as they were willing to use their secret data. It doesn't generalize well if you're explicitly trying to use it as a sort of secret sharing scheme. But I do think it's reasonable to recommend "to get a private descriptor, redact your own keys". The fact that then any two parties will be able to reconstruct the xpubs feels like a curiosity to me rather than a deliberate part of the scheme....
...hmm, yeah...this actually could be a bit surprising. Two co-signers might upload their descriptors to different public places, without realizing that the other one did, and then they lose their privacy. So maybe this is too footgunny. I use this strategy for my own descriptors, but in my case I'm the only party so I am not vulnerable to this. Thanks for the tip about BIP 85 BTW! I have wanted to do this but didn't realize there was a standard way.
Ok in conclusion I think this is a much better idea than suggesting people redact their keys. They should instead store their full watch-only descriptor, but gpg-encrypt it to their own key using BIP85. For the avoidance of doubt, we should specify that they use the first key that they own and they should use a specific BIP32 path from it. |
Beta Was this translation helpful? Give feedback.
-
I agree and it lacks spend privacy for the old multisig type which has a legitimate use-case to know which keys signed.
You're welcome. First thing I did when I heard of BIP85 is write a script to find BIP85 child private extended masterkeys with fingerprints whose first 20-bits match a codex32 ID. Intended to create a "panic" wallet with less funds and boring transactions that could fool an attacker who knows 20-bits of bip32 fingerprint from a codex32 id. Takes about a minute per xprv found with a 20-bit match using 4 cores. Indexes don't need storage.
Sure and in multi-party, threshold signature, at least N - T others need the descriptor gpg-encrypted to their key also or you block recovery paths. You probably want to encrypt it to every key. Unless there's a good reason to exclude like a blabber mouth heir or a less trustworthy wallet vendor has it. Subject encrypting to at minimum N - T + 1 keys. "The first key you own" won't work if the threshold is 2 or decays and you only have your 2nd and 3rd key? The policy would let you spend but you can't if your descriptor won't decrypt. I suppose that could be deliberate to prevent collusion but seems that should be explicit in the policy, not subject to change if the cleartext descriptor leaks.
Covered by BIP85. |
Beta Was this translation helpful? Give feedback.
-
Ah, good thinking. Agreed, and agree with your reasoning.
Phew :) I hate needing (and lacking) a standard for tiny details like this. |
Beta Was this translation helpful? Give feedback.
-
That'd be cool but splitting the For unique scripts, an SSS upgrade to the If we do it for seeds, we should do it for extended pubkeys and descriptors. Both are secrets just to different degrees. |
Beta Was this translation helpful? Give feedback.
-
Reading last week's blog post:
This only works without accessing secret data if we don't lose the master extended public key. It'd be a shame to need to expose secrets to electronics again just to watch the wallet. Perhaps we should mention somewhere the master extended public key may be backed up by codex32 as well for very long-term or high-value storage? And maybe have a standard human-readable part for this application.
maybe
mxpuborxpubunfortunately has to be 513 bit data because we backup bip32 seeds instead of master private key data so chaincode has to be stored. I'd probably do this for a 50 year wallet.Beta Was this translation helpful? Give feedback.
All reactions