A user reported seemingly continous bitcoin rescanning. It turns out that those rescans were taking about 1 hour and 45 minutes. Combined with random disconnects and scheduled restarts, this resulted in vault spending most of its time rescanning. We should see if we can reduce rescanning times.
Edit: Here is my proposal:
The easiest solution would be to limit rescanning to a certain period, e.g. 1 month. It's not totally unreasonable, but when I was running a vault myself, I would often not run the client until I received a redeem (due to me not having a server to host on..).
If we want to fix this without additional assumptions, and without starting to maintain state outside of the bitcoin wallet, we have only 1 choice: to save state in the bitcoin wallet itself. We can create addresses with labels to store two pieces of information: the latest active_block_number and the bitcoin block number that we have scanned until. It's definitely a bit hacky but it would work..
For future reference, old proposal here:
Rejected solution
- when receiving an issue: import the address and add a label with the following name:
issue-<issueId>-unscanned
- rescan the chain for the blocks in which theoretically a payment could have been made
- after rescan is complete: change the label of the address to
issue-<issueid>-scanned.
When starting up, we iterate over all of the vault's issues. For each, we check if there are an address named issue-<issueId>-scanned, and if not, do the three steps above.
After one restart, all issues should have labels with the scanned label, and on any subsequent restarts, we only need to rescan for newly received issues.
A user reported seemingly continous bitcoin rescanning. It turns out that those rescans were taking about 1 hour and 45 minutes. Combined with random disconnects and scheduled restarts, this resulted in vault spending most of its time rescanning. We should see if we can reduce rescanning times.
Edit: Here is my proposal:
The easiest solution would be to limit rescanning to a certain period, e.g. 1 month. It's not totally unreasonable, but when I was running a vault myself, I would often not run the client until I received a redeem (due to me not having a server to host on..).
If we want to fix this without additional assumptions, and without starting to maintain state outside of the bitcoin wallet, we have only 1 choice: to save state in the bitcoin wallet itself. We can create addresses with labels to store two pieces of information: the latest active_block_number and the bitcoin block number that we have scanned until. It's definitely a bit hacky but it would work..
For future reference, old proposal here:
Rejected solution
issue-<issueId>-unscannedissue-<issueid>-scanned.When starting up, we iterate over all of the vault's issues. For each, we check if there are an address named
issue-<issueId>-scanned, and if not, do the three steps above.After one restart, all issues should have labels with the
scannedlabel, and on any subsequent restarts, we only need to rescan for newly received issues.