[chain] Make KeychainTxOutIndex more range based#1324
[chain] Make KeychainTxOutIndex more range based#1324evanlinjin merged 1 commit intobitcoindevkit:masterfrom
Conversation
0317415 to
775dad3
Compare
|
If I understand, you're using range in a couple different ways: in keychain/txout_index to range over keychains, and in spk_txout_index to range over derivation indexes - with Am I right in thinking these are similar but distinct concepts? or is it just two ways of looking at the same thing? |
|
|
Do we have a current need for this or can it be moved to a post 1.0 release as a non-breaking internal optimization? |
|
It's an API change for |
* Rebased bitcoindevkit/bdk#1324 onto master * Switch to this bdk_chain patch and use v0.12 * Small bdk API changes
* Upgrades bdk to version 0.12 with minor api changes. * Patches include keychain_txout_more_range changes from bitcoindevkit/bdk#1324, * Additionally includes an electrum-client with an upgraded rustls. * Frostsnapp no longer depends on ring.
* Upgrades bdk to version 0.12 with minor api changes. * Patch keeps the keychain_txout_more_range changes from bitcoindevkit/bdk#1324, * This bdk rev uses an updated electrum-client with upgraded rustls. * Frostsnapp no longer depends on ring.
775dad3 to
e6167aa
Compare
`KeychainTxOutIndex` should try and avoid "all" kind of queries. There may be subranges of interest. If the user wants "all" they can just query "..".
e6167aa to
fac2283
Compare
* Upgrades bdk to version 0.12 with minor api changes. * Patch keeps the keychain_txout_more_range changes from bitcoindevkit/bdk#1324, * This bdk rev uses an updated electrum-client with upgraded rustls. * Frostsnapp no longer depends on ring.
* Upgrades bdk to version 0.12 with minor api changes. * Patch keeps the keychain_txout_more_range changes from bitcoindevkit/bdk#1324, * This bdk rev uses an updated electrum-client with upgraded rustls. * Frostsnapp no longer depends on ring.
KeychainTxOut index should try and avoid "all" kind of queries. There may be subranges of interest. If the user wants "all" they can just query "..".
The ideas is that KeychainTxOutIndex should be designed to be able to incorporate many unrelated keychains that can be managed in the same index. We should be able to see the "net_value" of a transaction to a specific subrange. e.g. imagine a collaborative custody service that manages all their user descriptors inside the same
KeychainTxOutIndex. One user in their service may pay another so when you are analyzing how much a transaction is spending for a particular user you need to do analyze a particular sub-range.Notes to the reviewers
unused_spksto follow this rule because I want to delete that method some time in the future.unused_spksis being used in the examples for syncing but it shouldn't be (the discussion as to why will probably surface in Add wallet sync_request and full_scan_request functions #1194).BTreeMaps e.g.all_unbounded_spk_iters. It probably should be but I haven't made up my mind yet.This probably belongs after #1194
Changelog notice
KeychainTxOutIndexmethods modified to take ranges of keychains instead.Checklists
All Submissions:
cargo fmtandcargo clippybefore committingNew Features: