pull down to refresh
This is helpful.
And you got to exactly what I was worried about: if my descriptor is encrypted, I need to treat the passphrase/key for that encryption like another key in my multisig, because without it, none of us are going to be able to move my coins.
However, I think your model does have something that is interesting: assuming that I have a separate copy of the descriptor that I can backup on my own, having an encrypted version that lives elsewhere is very handy. Tying it to a set spending policies I determine is even cooler.
You may already be doing this, but what would be really cool is if the passphrase that encrypted the data in the enclave was derived from both the keys to the multisig that I keep so that I could use either one to decrypt the data.
Currently, there is no account recovery path. Your encryption key is derived from your passphrase, and neither is ever transmitted to or stored by the platform. If you lose your passphrase, we cannot recover your account or decrypt your vault data.
That said, you've raised a good idea. This could be an opt-in feature which will allow the user to enroll their hardware devices as recovery keys.
I think there's a bip (BIP 138) that is doing something like this.
I readen lot of documentation and spend hours on understanding these bip 138 concepts but they are pure technical term that a casual user like me won't understand however 30 CC for the link
Some additional information:
Vaults on XYZVault use our private Bitcoin node, address and transaction lookups are routed through a blind proxy.
Your browser derives addresses locally, then sends lookup requests to the proxy. The proxy forwards those requests to XYZVault’s private Bitcoin node, but it does not log request data, and the node does not receive account context. That means XYZVault may transiently handle address or transaction queries, but we are not able to tie those queries back to a specific user or vault.
This is different from storing wallet data. XYZVault does not store your addresses, balances, or transaction history. Those are derived and computed client-side each time the vault loads. The proxy only exists so users can query chain data without relying on third-party public APIs.