-
Notifications
You must be signed in to change notification settings - Fork 390
Various improvements not included in #1203 (new) #1451
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
Conversation
1a249a7
to
300526b
Compare
@LagginTimes could you also rebase this please? Thanks! |
Also rename `descriptor_ids_to_keychain_set` to `descriptor_ids_to_keychains` and update it's documentation.
Change the out signature of methods `reveal_to_target`, `reveal_next_spk` and `next_unused_spk` to return a tuple of `(Option<spk(s)>, changeset)` instead of `Option<(spk(s), changeset)>`. This makes the API more consistent. Also refactored various helper methods to take in a descriptor instead of a descriptor id. `.expect` calls now exist outside of these helper methods, making it more obvious where they are being called. Docs are updated to reflect the new API.
Rename `descriptor_ids_to_descriptors` to `descriptors`. Rename `descriptor_ids_to_keychains` to `keychains`.
8577012
to
910a5b5
Compare
cd12fa2
to
2d4adbd
Compare
2d4adbd
to
a5142de
Compare
// a keychain, we return it with the highest-ranked keychain with it. We rank keychains by | ||
// `Ord`, therefore the keychain set is a `BTreeSet`. The earliest keychain variant (according | ||
// to `Ord`) has precedence. | ||
keychains: HashMap<DescriptorId, BTreeSet<K>>, |
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 have a second thought about this renaming. What do you think about: ids_by_keychain
and keychains_by_id
?
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.
My initial thought is, if we're simplifying descriptor_ids_to_keychains
to something like keychains_by_id
, would it make sense to do something similar to keychains_to_descriptor_ids
?
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 meant keychains_by_ids
to replace descriptor_ids_to_keychains
. I was suggesting it because the wording makes more sense to me. However, ids_to_keychains
can work too.
Edit: Sorry @LagginTimes I completely misread the comment. Yes, since one field is a reverse-index of the other so it makes sense that the names correlate.
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.
🤔 my 2 sats is names should match plurality of the related data. So something like:
keychain_to_descriptor_id
, maps one keychain to one descriptor_iddescriptor_id_to_keychains
, maps one descriptor_id to multiple keychains
This is looking good. Curious what others think about my comments. |
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.
// a keychain, we return it with the highest-ranked keychain with it. We rank keychains by | ||
// `Ord`, therefore the keychain set is a `BTreeSet`. The earliest keychain variant (according | ||
// to `Ord`) has precedence. | ||
keychains: HashMap<DescriptorId, BTreeSet<K>>, |
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.
🤔 my 2 sats is names should match plurality of the related data. So something like:
keychain_to_descriptor_id
, maps one keychain to one descriptor_iddescriptor_id_to_keychains
, maps one descriptor_id to multiple keychains
I was just on a call with @LLFourn this morning. It turns out that having the internal The problem is evident when we query outputs in a given keychain ( The first solution (the one @LLFourn is working on) is to use keychain ( The alternative is to continue to have the internal Edit: I created a ticket (#1459). |
Replaced by #1463 |
8dd1744 refactor(chain): compute txid once for `KeychainTxOutIndex::index_tx` (志宇) 639d735 refactor(chain): change field names to be more sane (志宇) 5a02f40 docs(chain): fix docs (志宇) c77e12b refactor(chain): `KeychainTxOutIndex` use `HashMap` for fields (志宇) 4d3846a chore(chain): s/replenish_lookahead/replenish_inner_index/ (LLFourn) 8779afd chore(chain): document insert_descriptor invariants better (LLFourn) 69f2a69 refactor(chain): improve replenish lookeahd internals (LLFourn) 5a584d0 chore(chain): Fix Indexed and KeychainIndexed documentaion (Lloyd Fournier) b8ba5a0 chore(chain): Improve documentation of keychain::ChangeSet (LLFourn) 101a09a chore(chain): Standardise KeychainTxOutIndex return types (LLFourn) bce070b chore(chain): add type IndexSpk, fix clippy type complexity warning (Steve Myers) 4d2442c chore(chain): misc docs and insert_descriptor fixes (LLFourn) bc2a8be refactor(keychain): Fix KeychainTxOutIndex range queries (LLFourn) 3b2ff0c Write failing test for keychain range querying (LLFourn) Pull request description: Fixes #1459 This reverts part of the changes in #1203. There the `SpkTxOutIndex<(K,u32)>` was changed to `SpkTxOutIndex<(DescriptorId, u32>)`. This led to a complicated translation logic in `KeychainTxOutIndex` (where the API is based on `K`) to transform calls to it to calls to the underlying `SpkTxOutIndex` (which now indexes by `DescriptorId`). The translation layer was broken when it came to translating range queries from the `KeychainTxOutIndex`. My solution was just to revert this part of the change and remove the need for a translation layer (almost) altogether. A thin translation layer remains to ensure that un-revealed spks are filtered out before being returned from the `KeychainTxOutIndex` methods. I feel like this PR could be extended to include a bunch of ergonomics improvements that are easier to implement now. But I think that's the point of #1451 so I held off and should probably go and scope creep that one instead. ### Checklists #### All Submissions: * [x] I've signed all my commits * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md) * [x] I ran `cargo fmt` and `cargo clippy` before committing #### Bugfixes: * [x] This pull request breaks the existing API * [x] I've added tests to reproduce the issue which are now passing * [x] I'm linking the issue being fixed by this PR ACKs for top commit: evanlinjin: ACK 8dd1744 Tree-SHA512: 283e6b6d4218902298e2e848fe847a6c85e27af4eee3e4337e3dad6eacf9beaa08ac99b1dce7b6fb199ca53931e543ea365728a81c41567a2e510cce77b12ac0
Closes #1439
Description
These were tasks that were intended to be included in #1438.
See #1438 (comment).
descriptor_ids_to_descriptors
todescriptors
.descriptor_ids_to_keychains
tokeychains
.Various improvements not included in #1203 #1438 (comment) to that of the version in
Further work on #1203 #1428
Original Ticket Description
Adds various improvements to the work of #1203. These were missed out while cherry-picking, or review comments left in #1428 that were forgotten:
keychains_to_descriptors
tokeychains_to_descriptor_ids
which simplifies the field. This was mentioned here and included in Further work on #1203 #1428, but an older commit was cherry-picked.KeychainTxOutIndex
fielddescriptor_ids_to_keychain_set
todescriptor_ids_to_keychains
was missed out as an older commit was cherry-picked. This change to naming shows the direct relationship betweenkeychains_to_desriptor_ids
anddescriptor_ids_to_keychains
(one is directly a reverse lookup of the other).reveal_to_target_with_id
toreveal_to_target_with_descriptor
, reasoning mentioned here.In addition to this, I changed the output signature of
reveal_to_target
,reveal_next_spk
andnext_unused_spk
methods to return(Option<spk(s)>, changeset)
, whereas previously it wasOption<(spk(s), changeset)>
. This makes the API more consistent as theChangeSet
is always returned, andreveal_to_target
andunbounded_spk_iter
-esc methods all returnOption<SpkIterator>
(which we can.flatten()
).Notes to the reviewers
Not all changes in this PR are Changelog-worthy. I.e. renaming of internal variables to increase readability, changing code comments, refactoring private methods - are all excluded from the changelog.
Changelog notice
KeychainTxOutIndex
methods to always return a changeset. This makes the API more consistent.KeychainTxOutIndex
methods to return spks asScriptBuf
instead of references (&Script
) to reduce lifetimes of mutable borrows.Checklists
All Submissions:
cargo fmt
andcargo clippy
before committing