Ran
|
Files
46
|
Run time
1s
|
Badge
Embed ▾
README BADGES
|
push
github
Merge bitcoindevkit/bdk#1494: Add documentation for Electrum's full_scan/sync 7b5657e23 docs(electrum): enhance API docs for fetch_prev_txouts argument (thunderbiscuit) Pull request description: This PR also serves as an issue; it can't really be merged as is. I just didn't want to open an issue and just ask for better docs and instead decided to open a PR with some unfinished new API docs. I am working on a page for the Book of BDK that focuses on bdk_wallet + bdk_electrum syncing. A few things have been unclear to me, and I think slight additions to the API docs would fix that for others. ~~1. I was wondering what exactly this `confirmation_time` field on the `bdk_chain::ConfirmationTimeHeightAnchor` type represents. After digging into it (at least for the electrum client), it represents the timestamp specified by the block header where the tx was confirmed. _Question: I'd like to confirm that this always the case, e.g. that this is the timestamp used in cases where your client is an Esplora or bitcoind RPC node?_ If so, my addition to the sentence will make sense and is ready to go.~~ Edit: this is no longer a type after the rebase. 2. I think it'd be great to add context to the `fetch_prev_txouts` argument on the full_scan and sync methods on the `BdkElectrumClient`. It says that this is necessary for "fee calculation". What does that mean? I assume it means "for calculating the fee rate on the given transactions"? (let me know if that's wrong). Even so, I'm left wondering what happens if I don't fetch them. Will my fee calculations be just plain wrong? Or will they be unavailable? A bit more context for the caller of the method would be great here. If someone knows the definite answer to this let me know and feel free to propose a doc line and I'll amend the commit! ### Checklists * [x] I've signed all my commits * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/... (continued)
10915 of 13340 relevant lines covered (81.82%)
13527.8 hits per line
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line |
---|