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)
There is nothing stopping you from tar/zipping up, encrypting and storing your own blackbytes as data anywhere public, even on Byteball. But thats just reckless in my opinion, aside from increased costs.
There is really no benefit to storing the whole thing in Byteball, if you actually are so certain of your encryption and passwords not getting compromised store it elsewhere were costs are lower. Compared to say storing the data in ipfs and instead paying lower fee by storing the hash to the ipfs data in Byteball. Well actually there is something to explore here.
Like this, tar compress the blackbytes data, encrypt with AES passphrase, the sha256sum of the blackbytes.data.tar.bz2.enc is published to ipfs (you are seeding it now). The sha256sum+salt of your passhprase (or just bcrypt or whatever that thing is called) is published as ipns name pointing to the sha256sum of encrypted data. Now you can look up your blackbytes encrypted data if you know the passphrase and lookup in ipns what the hash to the encrypted data is. This ipns name is what you store in Byteball if you really want.
IPNS, because if you want to update your data, when sending/receiving blackbytes, you publish that, and repoint ipns to the latest blackbytes-encrypted data which you now also seed.
In this way you offload everything to ipfs/ipns and really you dont need to keep any new hashes in Byteball. If you want to help seed/share others encrypted data, and others to help you, well, thats easy if you want to just publish hashes and begin sharing things you dont know what it is, and if you want economical share only other people who also share/constribute, thats more tricky.
I wouldnt do this though.
https://supload.com/HkwYB7Mdx
