# BDK 1.0.0 - Priorities, Planning, Scope definition

## Agenda

* Evan's pitch (shoutout to @LLFourn for these ideas).
* Problems with the current chain src APIs.
* Esplora: need to lock wallet again to fetch missing checkpoints.
* Electrum: need to refer back to wallet to fetch full transactions. Not efficient. We should use electrum with pub/sub model.
* The `TxGraph::missing_heights` API is also problematic in general: https://github.com/bitcoindevkit/bdk/issues/1354
* Solution(s).
* [Change checkpoints from linked-list to skip-list.](https://github.com/bitcoindevkit/bdk/pull/1369) Checkpoints were linked-list so we can cheaply share the `LocalChain`'s state to chain-sources. This is very good for block-by-block chain sources where we only need to worry whether the update connects with the original state (to do so we iterate backwards from the tip). However, for spk-based chain-sources, we may be introducing transactions from way back. We need a quick way to determine which new checkpoints to fetch when we introduce these transactions. The old solution was to maintain an index of the linked-list (as a height->hash map in `LocalChain`). This means we need to refer back to the `LocalChain` to determine which checkpoints we need to fetch. Enter skip lists. Skip list makes querying from a checkpoint tip efficient so instead of maintaining a separate index, we can just query from a checkpoint. Now we can determine which new checkpoints to fetch without refering back to the `LocalChain`.
* [Wrap transactions with `Arc`](https://github.com/bitcoindevkit/bdk/pull/1373). This allows us to have the chain-src cheaply have a view of all transactions fetched. Electrum chain source will not have to refer back to the receiving `TxGraph` and just always send `Arc<Transaction>` as an update. The additional benefits of this is more memory savings since `ChangeSet`s can also be of `Arc<Transaction>`s.
* New API?
* This allows us to complete what @notmandatory set out to do in https://github.com/bitcoindevkit/bdk/pull/1194.

            let things_I_am_interested_in = wallet.lock().unwrap().start_sync();
            let update = electrum_or_esplora.sync(things_i_am_interested_in)?;
            wallet.lock().unwrap().apply_update(update)?:

* Steve's priorities

1. Resolve known bugs
2. Upgrade rust-bitcoin to 0.31 #1177
3. Descriptors in wallet changesets #1203
4. Evan's above syncing fixes and #1194
5. Sqlite DB #1128

Anything else that can be move out to post-1.0 I want to move.

We have projects who are waiting for 1.0 and need it by April/May.

We also need to update tutorial docs (book of bdk) and language bindings projects.

Meeting notes:

On Evan's points:
- Updating the chain sources (esplora and electrum) is the hard part. Localchain part shouldn't be so long (2 PRs). Crucial change before anyone uses it, simplifies a lot. A little different between esplora and electrum, since electrum is the much bigger change (caching, Arc...).

On Steve's priorities:
- We could stabilize 1.0 without the Sqlite DB part that could come after that

**Other things needed:**

- `bdk::Wallet`'s get address API is unwieldly.
- Since wallet is opinionated already, force users to specify two unique descriptors for internal/external.
- `Wallet::get_address` does not make sense. Have separate methods for getting: new address, new unique address, and revealed addresses. These methods will take in `KeychainKind` as input.

vmammal:
- Rename bdk crate to bdk_wallet for 1.0?

Lloyd:
- versioning bdk wallet changeset -> it can't be postponed
- can get rid of wallet's planning module since this functionality is already in `rust-miniscript`. Also related: #642 can be avoided if we just use the planning module.
- `Wallet::get_utxo` exists, but we don't have `Wallet::get_output`.
- Remove changeset generic for wallet changesets.
- 3 wallet transaction API tickets that are related (group them): Wallet state, `transactions()` method, #794,
- To fix `last_seen` issue, get the user to pass in the `last_seen`.