Wallet Backup - future improvements

[St333p]

I'd like to propose a few possible improvements to the wallet backup strategy of rgb-lib, resulting from a review that took place in October 2023.

Context

Any bitcoin wallet that follows proper standards has a deterministic structure, so that it can be completely recovered from the sole seed, which can be conveniently stored as a mnemonic passphrase.

On the contrary, an RGB wallet needs to store additional metadata for each token allocation, since it relies on client-side validated data that is kept from being publicly available on-chain. The mnemonic passphrase is not enough to recover RGB funds: spending wallet UTXOs without knowing their RGB allocations, and thus failing to transfer them accordingly, effectively burns RGB tokens.

As a result, a proper backup structure for additional data is necessary before spreading this technology to the wider public, unlocking the ability to hold and transfer significant value through it. Different backup strategies can apply to different security settings and risk exposure to hardware failure.

Interestingly, this requirement is pretty common for layer 2 solutions, so some concepts can be found in Lightning Network nodes as well.

Flexible security settings and cryptographic building blocks

Advanced users of rgb-lib may want to tune cryptographic systems and security parameters for the wallet backup operations, depending on their target platforms or security setting. For instance, in a tightly resource constrained setting (IoT), where involved amounts tend to be rather small, one may want the password-based key generation to be less resource intensive; similarly, if AES hardware acceleration is available, it can represent a better encryption algorithm than chacha20.

As a result, it may be nice to expose users a choice over the following:

• Key-derivation function: scrypt is a nice default choice, but argon2id may perform better in less resource-constraied environments
• Key-derivation parameters: rgb-lib picked a safe set of default parameters for scrypt, but one may want to use stricter ones to be more future-proof or smaller ones where performance is important
• Encryption algorithm: AES is an arguably better alternative to chacha20 if hardware acceleration is available
• Encryption key size: If one wants to achieve quantum resistance, a key size larger than the default one should be chosen
• Encryption passphrase: since the bitcoin mnemonic is required, but not enough, to recover funds, it is the most natural choice for backup encryption passphrase as well. However, one can think of settings in which using a second passphrase is required or desirable, for instance in a watch-only wallet linked to an hardware security module for signing

Note: It is very important that every user-dependent information is stored in cleartext along with the encrypted backup, otherwise recovery might become impossible in the future. See #30 for a first step in this direction.

Perform operations synchronously with their backup

The current backup strategy leaves users vulnerable to loss of funds in case of failures happening between completion of an operation and the following backup update.

A first mitigation strategy involves starting a backup update process after any change that affects the wallet status. However, this requires to either lock wallet operation while the update is in progress or to make the backup process aware of the operation being backed up so that it can ignore unrelated changes happening to the wallet database in the meanwhile.

This strategy would still not prevent 100% of accidents, since any kind of failure happening while the backup is in progress could still result in funds loss. To completely prevent this, it becomes necessary to make every operation synchronous with the corresponding backup update. This would only be possible by making the backup process more context-aware, so that it only affects the changed section of the cyphertext and not the whole encrypted backup file. An alternative solution would be to enable synchronous mirroring at the wallet database and filesystem level, which would require some deeper analysis.