志宇

Also, if https://github.com/rust-bitcoin/rust-miniscript/pull/476 gets merged, we need to do +5 for [`TXIN_BASE_WEIGHT`](https://github.com/bitcoindevkit/bdk/blob/master/src/wallet/coin_selection.rs#L122). * +1 WU for witness field stack size varint * +4 WU for scriptSig size varint

``` ---- blockchain::rpc::test::bdk_blockchain_tests::test_taproot_key_spend stdout ---- - wv satisfaction weight: 65 pool: [(0, WeightedValue { value: 50000, weight: 225, input_count: 1, is_segwit: true })] selected: index=0, value=50000 create_tx: weight=563, fee=141, feerate=0.25044405sats/wu...

Coin selection algorithms should take `min_absolute_fee` and `target_feerate` into consideration on the get-go (and only succeed when both constraints are satisfied). `bdk_core` will solve this issue, WIP here: https://github.com/LLFourn/bdk_core_staging/pull/21

**To do** - [ ] `LargestFirstCoinSelection` should use `Ref` as a field (otherwise it will be inconvenient/confusing to use). I've converted this to draft again. - [ ] Write an...

> Concept ACK! I just wonder, will this method change again after the bdk-core integration, or do you think it can remain the same? I'd avoid breaking this API in...

> The idea of paging makes good sense, but is there a reason to not save the next derivation index in the existing wallet DB as we do with other...

> Also, a suggestion: maybe you don't remember, but the old rpc implementation used the label of a fixed address as a "storage section" to save essentially the RpcImportParams. What...

@afilini do you think this is still worth working on?

This is my proposal (as mentioned in https://github.com/bitcoindevkit/bdk/pull/1272#issuecomment-1891319255): > I think we should have a file `chain/types.rs` that contains all smaller public traits and structs (replacing `chain_data.rs` and `tx_data_traits.rs` files)....

The conclusion is the following: > Remove the `tx_data_traits.rs` file and move all of it's contents into `chain_data.rs`. Also move the `Balance` struct into `chain_data.rs`.