# Meeting Minutes 11 (`bdk_chain` Redesign)

###### tags: `BDK Core` `Meeting`

:::info
- **Location:** Online
- **Date:** 21st March 2023, 23:00 (UTC)
- **Agenda:**
- [Evan's `bdk_chain` Redesign Analysis and Proposal](/q3CjGJ6eTmex6Pz_wEhmZA)
- **Participants:**
- @notmandatory
- @danielabrozzoni
- @LLFourn
- @evanlinjin
- **Reference:**
- [Issue #895](https://github.com/bitcoindevkit/bdk/issues/895)
- [Evan's `bdk_chain` Redesign Analysis and Proposal](/q3CjGJ6eTmex6Pz_wEhmZA)
:::

**Decisions:**

* Yes, we should go forward with `#895`.

**Questions:**

* Does nakamoto allow us to get height from blockhash?
* Can the new sync flow of the BDK Chain redesign allow us to enforce "Order" when syncing LDK?
* Sort `Confirm::get_relevant_txids` -> Sort blockhashes in order and ask oracle if they are still in chain?
* If not, unconfirm txs that are reorged out
* TODO: Evan finish this.

**What else needs to be worked on:**

* Async examples: Syncing and getting balance at the same time. Lets brainstorm on this. Make a placeholder issue!
* Improving `bdk::Wallet` API; addresses, multi-descriptor? Or whether `Wallet` is even still necessary? For multi-descriptor, is descriptor trusted/non-trusted?
* Descriptor templates (separate crate).
* MSRV!!! CI, make sure certain subsets compile with rust v1.48. Set different `.toml`s for different MSRVs - does this work with cargo workspaces? CI, test compile with `no-std`.
* Expose `TxGraph` from `Wallet`. The cargo file need to be named `cargo.toml`, so can we put it in multiple directories?
* Kill `TransactionDetails`, get details of txs via methods from `Wallet` instead. Ensure rich data we have from `bdk_chain` can be observed from `Wallet`.
* Should we force wallet to use `LocalChainOracle` (model the chain locally?). Should we force wallet to use a specific chain source? If wallet is opinionated to use `LocalChainOracle`, user does not need to worry about different chain-specific behaviour.
* Always enable `no-std` (it means extra dependencies always), but should be fine. Or... we can document for people in `no-std` environments the features they need to enable.
* Remove `bdk::Error` (split it out, or remove it). This should not be a giant enum. Have error types for specific errors.

**Other thoughts:**

BDK 1.0 is not `bdk_chain` 1.0, the `bdk_chain` API can be considered "unstable" as in it may be changed around. We just need to guarantee that `bdk::Wallet`'s API is stable for BDK 1.0.