Just as a more polished version of this brain-fairt idea above of doing on-chain bookkeeping. Just like you can put all one-time use addresses in a seperate branch for derivation, you could have another ‘special’ branch where you do book keeping. E.g.
bet1 | Address m/0/0/1/1 | disposable
bet2 | Address m/0/0/1/2 | disposable
Bookkeeping | Address m/0/0/2 | permanent
grinmint | Address m/0/0/3 | permanent
f2pool | Address m/0/0/3 | permanent
The idea of the special bookkeep address is that the user can click a button, to make an on-chain backup.
Once the user presses the button, all one time use addresses that were used and possibly even permanent addresses that were used are send to the special bookkeeping adress as dust transactions containing the information of each derivation path used. In case of one time use addresses this means these addresses are burned, e.g. m/0/0/1/1 and m/0/0/1/2 should not be used again. In the case of permanent addresses, this would store the information only readable to the user that these permanent addresses were used, but the description would be lost. This should be done very minimally, e.g. only the last two digits of the address are send to the bookkeeping address.
E.g. m/0/0/1/1 = “11” = dust transaction 0.000000011 (not sure how many digits after the comma Grin uses, I assumed 9).
By no means to I say the above idea is worth the costs, but it is just an interesting idea to allow users occasionally backup information online in case of losing the wallet file, since the mnemonic seed will regenerate the bookkeeping address and find all associated bookkeeping outputs. The address is only meant for bookkeeping from the main address, outputs should never be spend in order to retain the data. Since only a few transactions are involved, the costs of this on-chain bookkeeping are minimal. Alternatively, information could be stored as a range, e.g. temporary address 1 to 100 would be t100 = 0.116 49 48 48 Grin to be send to the Bookkeeping address. Since the timing of these backups is not associated to the time the addresses are used, and since they only link to the main address, no privacy should be lost to the user, just a dust amount of Grin to facilitate the bookkeeping.grinning:
For future research, using multiple transactions using the last digit to indicate the following transaction should be read for full information could be used to further “compress” how information is stored in the dust part of transactions. It could even be used for any other arbitrary type of information to be stored on chain, e.g. a text message. This however serves less function since such a message could also be included in the transaction information, I think there even is or used to be a field for this in the transaction protocol. The only added benefit is that the information could be stored permanently similar to how OP_RETURN is used to store information encrypted on chain. In the case of Grin the information is however much stronger protected since it is indistinguishable from normal transaction since it is a normal transaction with the only difference that the value is used to encode information.