Closed Sword-Smith closed 1 year ago
I'm a little confused. Please elaborate.
If you're running an archival node everything that's needed to restore an MSMP (with an empty wallet DB) should be stored in separate files, not only in the database.
Storing sender randomness and AOCL index should be sufficient. From this data, the mutator set membership proof can be restored.
ArchivalMutatorSet
has a method called restore_membership_proof
that we can call on startup. The new data structure IncomingUtxoRecoveryData
contains the data needed. The function to restore the database should probably be implemented as a method on GlobalState
since it will read data from both the wallet and the archival state.
This function should take the digest of the block tip, maybe as a lock on LightState
, and then see if it can find a matching MonitoredUtxo
in the database for each IncomingUtxoRecoveryData
instance. If it cannot, it can generate a new MonitoredUtxo
from the IncomingUtxoRecoveryData
and the ArchivalMutatorSet
and then insert this into the wallet DB.
With e1327631512d3ddc90947870871f27affca62ed7, we can now restore monitored UTXOs/the wallet database from disk.
Storing outgoing randomness can be handled through another issue. Closing this as completed.
It's not enough to store incoming and outgoing randomness in the DB, as this is cryptographic data without which funds might be lost. As the DB schema changes, this randomness can get lost if it's not also written to disk in the files
incoming_randomness.dat
andoutgoing_randomness.dat
found in<data_dir>/<network>/wallet
.For each incoming/outgoing transaction, we probably want to store the randomness as well as the block height and block digest in which the UTXO was mined. Then recovering the membership proofs and populating the wallet DB should not be too hard.