-
Notifications
You must be signed in to change notification settings - Fork 412
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_descriptorstodescriptors.descriptor_ids_to_keychainstokeychains.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_descriptorstokeychains_to_descriptor_idswhich simplifies the field. This was mentioned here and included in Further work on #1203 #1428, but an older commit was cherry-picked.KeychainTxOutIndexfielddescriptor_ids_to_keychain_settodescriptor_ids_to_keychainswas missed out as an older commit was cherry-picked. This change to naming shows the direct relationship betweenkeychains_to_desriptor_idsanddescriptor_ids_to_keychains(one is directly a reverse lookup of the other).reveal_to_target_with_idtoreveal_to_target_with_descriptor, reasoning mentioned here.In addition to this, I changed the output signature of
reveal_to_target,reveal_next_spkandnext_unused_spkmethods to return(Option<spk(s)>, changeset), whereas previously it wasOption<(spk(s), changeset)>. This makes the API more consistent as theChangeSetis always returned, andreveal_to_targetandunbounded_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
KeychainTxOutIndexmethods to always return a changeset. This makes the API more consistent.KeychainTxOutIndexmethods to return spks asScriptBufinstead of references (&Script) to reduce lifetimes of mutable borrows.Checklists
All Submissions:
cargo fmtandcargo clippybefore committing