A simple backup scheme for wallet accounts

The recent discussion highlights a significant limitation in the proposed backup computation method for cryptographic wallets, particularly in relation to BIP138. The new method requires each participant to independently compute and maintain their own backup using their signing devices. This requirement could hinder the practicality of the scheme, especially for scenarios that align with the primary objectives outlined by the authors of BIP138. These objectives predominantly focus on facilitating recovery spending paths without necessitating continuous active participation from the recovery partners.

In contrast, BIP138 simplifies the process considerably by allowing wallet creators to obtain an xpub from their recovery partners and subsequently hand over the encrypted backup. This approach eliminates the need for any further action from the partners unless recovery becomes necessary. For example, in cases where a custodian is used as a last-resort recovery option, the backup can be stored securely in personal cloud storage. Access to this encrypted backup is not provided to the custodian unless needed, ensuring that they remain unaware of the user's spending activities. This setup is convenient as it allows for the decryption of the backup by the custodian using their key, should the original user face issues like inability to decrypt due to various reasons.

Furthermore, considerations regarding privacy and security methods such as taproot and SegWit have been raised. These involve techniques for blinding xpubs if they are only employed in the recovery path, which enhances security but complicates the backup process. Overall, while innovative, the proposed method introduces complexities that may not fully align with the intended use cases of BIP138, thus potentially limiting its applicability in certain scenarios.