bdk icon indicating copy to clipboard operation
bdk copied to clipboard

Wallet's persistence should have a fixed "header" section

Open evanlinjin opened this issue 2 years ago • 4 comments

Describe the enhancement

Add a fixed header section to the wallet's persistence.

This is initially proposed by @LLFourn: https://github.com/bitcoindevkit/bdk/pull/1178#discussion_r1379454497

Use case

This can be used to store data that are mostly unchanging such as network type, version, etc.

Implementation proposal

pub struct Database<H, C>: PersistBackend<C> {
    fn write_header(&mut self, header: H) -> Result<(), Self::WriteError>;
    fn load_header(&self) -> Result<H, Self::LoadError>;
}

evanlinjin avatar Nov 02 '23 03:11 evanlinjin

During today's discussion in the Lib Team Call, we were assuming that this issue requires breaking changes and so that it could be required for alpha.3. What do you think @evanlinjin?

nondiremanuel avatar Nov 07 '23 15:11 nondiremanuel

I can put together a draft for this. The plan will be:

  • Add a trait Database to bdk_chain::persist, and impl Database for bdk_file_store::Store
  • Add a struct in bdk::wallet for holding wallet metadata such as the bitcoin network (descriptor hashes should eventually go here as well).
  • Drop network member from wallet::ChangeSet and replace it with something like meta: Option<Meta>

I'm happy to collaborate if there are other ideas out there, and let me know if this isn't the solution you had in mind.

After staring at the code in store.rs, I tend to view persistence in terms of a flat file, so I'm wondering if the header concept will generalize just as well to an sqlite context - or if that would entail a totally new interface.

edit: I will shelf this idea for now

ValuedMammal avatar Dec 12 '23 00:12 ValuedMammal

I think it will map fine to sqlite. My main concern is that this isn't a "pants on fire" problem for us yet. I'm not sure it's worth the API complexity to remove this error case where you try and change the network or genesis block at a later point. The actual APIs will never produce this changeset so we're talking about making some (but not all) programmer errors impossible. If you are applying the wrong changeset to the wrong thing is it really a big benefit to remove the invalid action of changing the network even when this still can add wrong transactions or blocks to the thing?

Definitely bring this up on dev call if you haven't already to see what others think.

LLFourn avatar Dec 12 '23 01:12 LLFourn

I agree this isn't a critical issue and should be pushed to the post 1.0.0 milestone.

notmandatory avatar Mar 20 '24 02:03 notmandatory