Quote from: tonych on February 03, 2017, 11:46:27 PM

Quote from: freezal on February 03, 2017, 08:36:27 PM

Quote from: tonych on February 03, 2017, 06:19:50 PM

Quote from: freezal on February 03, 2017, 04:53:44 PM

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.

I assume you are not suggesting system-wide seed which would then be known by everybody

Certainly not

, I meant "one seed per each asset class" within each wallet.

Thank you for all clarifications.
This whole thing increasingly looks like a solution in search of a problem now.

I feel now like wasting your time and rather go back to the white paper, but I'd like to clarify one last point: see below

Quote from: tonych on February 03, 2017, 11:46:27 PM

If the seeds are per user, the problem remains. A user can encrypt his own transactions but he has to also store and forward (when sending balckbytes) the coin histories which include previous transactions created by other users. Then he has to know the keys that these previous owners used to encrypt their private payloads, and the number of these keys is as large as the number of previous owners of each coin.

I meant to say that when you receive the asset you receive all its past historic data, like today I think. You'd receive the whole thing unencrypted from the sender.
Then you'd encrypt it with a seed generated new key of yours and save everything back as a payload in the public DAG (forget about compression as this data probably shouldn't compress well anyway, addresses, signatures, etc.).
When it comes time to send these tokens to someone, your wallet would have retrieved it from the DAG, unencrypt it with you key (calculated from your seed), maybe save it in your local database (which now function as a local cache) as it does today, generate the new transaction and send it to the counterpart using the same mechanism as it does today. Then the process would repeat all over again by the new receiver.
Note that after each transaction reaches finality state, the payload of the previous transaction could somehow be pruned as not needed. As today any owner of a token could only access previous history of it and wouldn"t be allowed to see future transactions.

Quote from: tonych on February 03, 2017, 11:46:27 PM

Quote from: freezal on February 03, 2017, 08:36:27 PM

Quote from: tonych on February 03, 2017, 06:19:50 PM

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.

I see your point. I'm suggesting multisig for hot wallets as used by regular users, it allows to avoid the pain of having to backup after each transaction.
When you use cold wallets, I assume that convenience is not your primary concern and the transactions are rare, in this case having to backup after each transaction is not such a big issue compared with other steps you have to do to unlock the cold wallet.

Note that you can split the backup into two parts: the seed, which is small and can be stored on paper wallet, and the private payloads stored in the sqlite database. Even if the private payloads are stolen, they cannot be used without the seed, hence your privacy might be affected but the security is not compromised.