provide a "light backup" option that works for the use-case of wanting to protect spending rights only

OK so, according to https://wiki.byteball.org/backups (and the app itself):

Byteball uses a single extended private key for all wallets, BIP44 is used for wallet address derivation. There is a BIP39 mnemonic for backing up the wallet key, but it is not enough. Private payments and co-signers of multisig wallets are stored only in the app's data directory, so better use the built-in backup function!

But, if i understand correctly (please correct me if i’m wrong):

• the .sqlite database has 59 tables and 113 indexes
• multisig wallets are recommended “best practise” and so “most people” should/will have them
• private payments are desirable or critical to some people but irrelevant to many others
• a full backup of the entire .sqlite database could be equal to a full backup of the entire DAG if you’re running a full hub, which can be many GB and in the future TB or even PB

So, the use-case of only wanting to preserve/secure/transfer the basic right to spend your bytes on the network in the most minimal and robust way (no chance of unrelated data being corrupted in the backup/restore process and ruining your day) is not really supported atm, but IMO should be.

I’ve been lurking in the #helpdesk chat in slack and see people complaining about corrupt databases, often corresponding to backup imports.

It seems these corruption issues would be far less likely and much easier to debug if the size of the backup itself was kept as small as possible.

[JulianTosh]

co-signers of multisig wallets are stored only in the app’s data directory

Well, you can thank me for making byteball 12.5 gigabytes more scarce than intended. #FML I only backed up the wallet seed and uninstalled it from my phone.

Why in the world is it set up that way? Either there needs to be a single recovery phrase for all wallets created, or individual backed up wallet seeds.

[thedavidmeister]

@tonyofbyteball well, assuming there’s a clear split between the two in the db structure, backing up less data means less can go wrong.

i don’t personally have a use case to back up the DAG, but maybe you might want to do something academic with it… but it is currently in the backup, so i assumed there is a reason?