-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store the last sync time and block height #459
Store the last sync time and block height #459
Conversation
My rename suggestion for |
Can we think about getting rid of the block height request in |
b47ef60
to
ca41644
Compare
Yup, that would be great. With that you would only need the network to sync, everything else would work offline as well, which is reasonable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM -- one thing I'd like you to consider changing.
src/database/keyvalue.rs
Outdated
@@ -82,6 +82,13 @@ macro_rules! impl_batch_operations { | |||
Ok(()) | |||
} | |||
|
|||
fn set_last_sync_time(&mut self, ct: ConfirmationTime) -> Result<(), Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I'm working towards adding different types of syncs. e.g. only sync addresses given out (no stop-gap). Maybe only sync addresses given out recently or only sync external keychain etc.
Could we leave the door open to that by making a SyncTime
struct which has the blocktime (whose type is unfortunately called ConfirmationTime
) as a field? It wouldn't hurt to add the local time to it. It's possible we'd want more metadata about a sync in the future and it'd make it easier from a DB updating point of view to serialize it in this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried implementing this but I got stuck because we don't have a way to get the tip hash with the current Blockchain
trait.
Since I would have to make a breaking change to the trait I'm thinking I might as well split it up like you described during our last call.
I'm not sure if we should hold this PR until that's ready or just go ahead and merge it without block_hash and add that later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think merge without that now and follow up with a PR that adds Option<BlockHash>
to the struct. I still think that we don't want to add this to BlockTime
but rather a struct like SyncTime
that contains a BlockTime
. Also SyncTime
should probably contain the UTC time that the sync was finished (in this PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah in my local branch I had a separate structure that contained the BlockTime
and the block hash.
I will add just the UTC time for now, we'll add the block hash in a following PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might consider adding a field for it in the sqlite table otherwise we have to do a table update and I'm not sure we have a db upgrade plan yet :S?
8486b60
to
8dfe72f
Compare
Looks like it needs a rebase to fix the CHANGELOG then is ready to go. |
This will be used to store the height and timestamp after every sync.
fields in the future
Done! |
8dfe72f
to
5830226
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 5830226
Description
Update the
Database
trait to allow storing the block height and timestamp of the lastsync
of aWallet
. This will allow having a rough estimation of the "current" height, even in parts of the code that don't have network access (tx creation, computing the balance, etc), at least in non-airgapped wallets that are periodically synced.After this is ready I'm planning to work on a PR to close #413, essentially making BDK aware of what can be spent and what is still not "mature" (initially only for coinbase UTXOs which are trivial, later on ideally also for any UTXO that has a timelock, which is a lot trickier).
Closes #455.
Notes to the reviewers
Opening this in draft mode, since it includes some commits from #454.
Random open points:
ConfirmationTime
because that name doesn't really make sense in this context, but I couldn't come up with a decent alternative. I'm open to suggestions if you have any.sync
, and then I would only return the latest one. That seemed pretty inefficient, considering that I was storing stuff that were by definition never read, so I changed it to the current structure.. but this feels more NoSQL-like so I still don't know which one I like best.Checklists
All Submissions:
cargo fmt
andcargo clippy
before committingNew Features:
CHANGELOG.md
Bugfixes: