Wallet recovery: sync federation history to preserve privacy #5584
Comments
|
My bad for not thinking about it before. But it a relatively straighforward addition to the current logic. We still need the eixsting logic from #5546 because Federation history can't have items that the client possibly did not not claim yet. So it will go:
In addition, during history scanning, we could observe some few most recent peg-in addresses that do not belong to the user performing the recovery and opportunistically query for them just a form of decoy. All in all, it's not going to be a lot of work, but I think we'll have to ship 0.4 with what we have now. In particular since we want to keep the wallet module in an "expert only recommended" state, and because the new scheme is just more robust and should have any possibility of accidentally losing funds, which is an important improvement in itself. |
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
See comments in the code. Fix fedimint#5584
Our current implementation of recovering the wallet client degrades privacy by batching requests to both the bitcoind backend (to check an address's history) and to the federation (to attempt claiming any potentially missed peg-ins). Since the queries are done for all tweaks controlled by the client until there's a gap of unused addresses, it's trivial for the federation to correlate the addresses to a single client even if the requests are made over separate Tor circuits.
Instead of iterating through all tweak indexes on the client until we find a tweaked address without history, the client can download the history of session outcomes of the federation, similar to fedimint-observer. The client can then reference the local copy of the full history of peg-ins to the federation without revealing to the federation the addresses the client tweaked. This also obviates the need to query a bitcoind backend to check if an address has history for already claimed peg-ins.
More context in this PR thread
The text was updated successfully, but these errors were encountered: