owned this note
owned this note
Published
Linked with GitHub
# W31 Meeting Minutes
###### tags: `meeting` `lib`
:::info
- Link: https://github.com/bitcoindevkit/.github/issues/70
:::
## Agenda
- BDK 1.0 milestones and timeline
- Impossible to get everything we planned on all the alpha releases within the year. Proposal to split the activities in different main releases and to focus on the work of alpha.2 and some little more into BDK 1.0. Basically, this would mean to delay everything that doesn't change the API in particular. We want to have a stable 1.0 API for this year and to do so we need to reduce the scope. For alpha.3 all Coin selection, planning module, rust-miniscript upgrade could go to a "2.0" version, maybe next year. For alpha.4: better wallet errors can go to 1.0, the rest will be delayed. For alpha.5: "Electrum double re-org support" could slightly change the API so we keep it as a possibility, while the others should not change the API. So we will focus on the alpha.2 and we will have a new "alpha.3" with other possible edits of the API and then we will be ready to have a Beta version and tests for users, to develop Bindings / CLI changes on that version and docs, tutorials etc. Daniela points out that since planning module is already at a good point, it makes sense to add it to 1.0, finishing it and give it reviews. Vlad is already working on CBF, the suggestion is to not stop working in general on those filters but to keep an eye on the priorities. If something is ready before the 1.0 is finished, it can be included anyway, but the most important thing is to end priorities.
- BDK Review Club
- Daniela can evaluate if there is something that can be interesting for #1023 PR
- In general, it can be asked by reviewer to the author of the PR if it can be helpful
- Review club would be very helpful for #1034, #1040 and #1041 by Evan, probably next week. Let's collect review questions on those
- Review Begs?
- See list in the alpha.2 section
- Blockers?
### New Projects and Support
- [#1029](https://github.com/bitcoindevkit/bdk/issues/1029) Expose way to select only (n-)confirmed UTXOs for TX creation
- It will go into Coin Selection so it will probably go to next year and Daniela already provided a workaround that makes it not essential for now (tnull, who opened the issue, confirmed it)
- [#1027](https://github.com/bitcoindevkit/bdk/issues/1027) Support for codex32/BIP93 seed import7
- Andrew Poelstra will work on this code change on the BIP32 seed
- [#1047](https://github.com/bitcoindevkit/bdk/issues/1047) Make backend objects Send + Sync for compatibility with cln-plugin
- Send and sync issue on c-lightning rust plugin. It is not super priority but a good example for user request for our API
### Top BDK 1.0 PRs and issues
#### alpha.1
It was published! Let's celebrate!
#### alpha.2
- [#1023](https://github.com/bitcoindevkit/bdk/pull/1023): Upgrade rust-bitcoin to 0.30, miniscript 0.10
- Needs reviews. This PR updates master branch. Then also the maintenance branch will need to be upgraded
- Ordering of merging with other alpha.2 PRs is not very important, whatever comes first
- [#1034](https://github.com/bitcoindevkit/bdk/pull/1034) ChainOracle linked-list refactor
- Review ongoing
- [#1040](https://github.com/bitcoindevkit/bdk/pull/1040) RPC client refactor
- Needs reviews
- [#1041](https://github.com/bitcoindevkit/bdk/pull/1041) esplora client refactor
- Needs reviews
- [#1048](https://github.com/bitcoindevkit/bdk/pull/1048) Remove TransactionDetails from Wallet API
- Review is ongoing, small changes needed that Steve will update soon
- [#1022](https://github.com/bitcoindevkit/bdk/issues/1022) Unify changeset APIs between all structures
- Good to leave in alpha.2
### Top Maintenance PRs and issues
- [#1033](https://github.com/bitcoindevkit/bdk/pull/1033) Backport new taproot descriptor template (BIP86)
- Needs final review from write access user. Not top priority but good to go
- [#1039](https://github.com/bitcoindevkit/bdk/pull/1039) docs: add required style for commit messages
- More a discussion topic on how to make a conventional commits standard. We'll give it a try in the existing or next PRs, good practice for reviews even if without automation. Not top priority but good to add to the contributing guide
## Users
- Transaction builder important for justinrc, but the fact that it will be moved out is not a blocking issue. Stable 1.0 API for block by block syncing (improved by #1041 PR included in 1.0 and in review now) is the priority to solve some current issues on their side. Needs it next quarter
- tnull wonders about forward and backward compatibility for 1.0 and if there are guarantees also on future versions on data model and API compatibility. The way we see it is that a major version (e.g. from 0.x to 1.0 or from 1.x to 2.0) means breaking the API and data structure. It is possible that this will happen once a year. Evan points out that the migration should not difficult to get backwards compatibility with some adjustments for future versions -> it can be a good design objective for 2.0 and future versions
- issue by tnull on fee estimation: getting it from the client (Core, electrum...) is probably the best way at the moment because BDK can't do it anymore