Hi tonych,
Shower thought (almost certainly a stupid one as always happens when you don't exert deep thinking, as I haven't finished reading the white paper, and have no time right now to research feasibility):
Would it be possible to optionally (because it changes somewhat the privacy/anonymity model) save assets (including blackbytes) in the public DAG as a compressed and encrypted payload (not much differently of what is saved locally today) paying due commissions?
Maybe we could now use a different seed for each asset to generate private keys for them and some hash of these to encrypt assets payload after each transaction.
Wallets would scan the DAG trying to decrypt asset payloads to get balance and history (some optimizations may apply).
Somehow old saved payloads in the DAG could be pruned as assets carry their own history.
Pro:
- Massive improvement in usability, no need to back-up local assets after each transaction (simplicity is beauty).
Cons:
- Privacy model changes (thus to use it optionally) as now assets history only remains private as long as no one discover a way to decrypt the payload which is now publicly available.
- Increased storage requisites for the DAG (but it'd be optional and has costs)
If it were possible, users would have to store huge numbers of decryption keys because every payload has to be encrypted with its own key.
The idea was to generate those encryption keys from the random generated seed. When you need a random address for bytes you calculate/generate it from the seed. Encryption keys could be generated from a seed too (one seed for each asset class maybe for security reasons, i.e. one for blackbytes, other for asset X and etc.). If they are generated from a seed, only the seed need to be saved (one time operation).
If you already generate private keys from a seed for each non spended asset (I don't really know), you could generate encryption keys from those pks by calculating some hash from them, not needing an extra seed only for the encryption keys.
They would convey a subset of these keys (instead of he payloads) to the new owner when making a payment. The keys are smaller in size than the original payloads but still have to be stored privately and backed up, so the backup problem is not solved.
Maybe my deficiency, but my understand is that we could retrieve (and only the owner could) the same data we have today locally (for blackbytes for instance) from the DAG to the wallet, and with this the new transaction could occur privately, as it is today, between the parts. The receiver would than save the data in the DAG, instead of locally, using his own encryption keys generated from his own seeds.
The best solution of the backup problem is imho multisig.
Yes, this works but maybe not for all scenarios.
For high values and strict security models of some institutions (for instance, cold wallets) it's hard to imagine that your back-up depend on many devices on-line syncing between them. If the other idea works (which is unlikely cause it must have any number of flaws), only the seeds would need to be backed-up.
Please note that I am not even suggesting it to be implemented in Byteball.
It was only a thought exercise if you can find some time to teach.
. 