Oct 27, 2026: BDK Team Call

[notmandatory]

Note: I started this recording late so these notes don't cover the whole call.

Recent Accomplishments

• Nymius merged the “trigger integration” work in BDK SP and reported that this item is now complete.

• A draft CLI pull request was opened to migrate usage from the transaction builder to create_psbt, giving users a way to exercise and test the newer PSBT functionality through the CLI.

• Rashit expanded the scope of his BDK Wallet formatting and linting pull request so that it now enforces formatting and Clippy requirements more broadly within the PR.

• Rashit also opened a logging pull request for the Rust Esplora client; it is complete enough to await maintainer review.

• Steve created bug-focused tabs on several GitHub project boards and began triaging the large set of reported bugs, including filtering and roughly prioritizing the many LLM-generated reports.

• Summit attendees captured extensive BDK-related feedback and planning notes. Noah recorded BDK-specific items, Steve retained detailed raw notes and screenshots of the in-person planning board, and additional requests were recorded in Signal.

• Recent summit discussions surfaced concrete LDK requests, including reporting all transaction IDs replaced through an RBF chain rather than only the immediately replaced transaction, improving forward compatibility and synchronization, and tracking events for foreign transactions.

• The team began publicly working through the BDK 4.0 signer-removal question, including differences between BDK’s trust_witness_utxo behavior and Rust Bitcoin’s PSBT signing behavior.

Today's Plan

• Thunderbiscuit will create an Alpha 1 milestone and begin selecting a small, focused set of issues and pull requests that could realistically ship in the first BDK 4.0 alpha.

• Thunderbiscuit planned to remain after the call for several hours to triage BDK Wallet issues and PRs, prioritize the bug list, and build the initial Alpha 1 milestone; Steve offered to remain for another 30–60 minutes and contribute roadmap context from the summit.

• Steve will propose a public GitHub-based process for collecting future developer-call agenda items. The likely model is a dated GitHub Discussion where contributors can suggest topics and link issues or PRs, followed by maintainers finalizing the agenda before the call.

• Steve will continue rough-ordering confirmed bugs on the planning board, placing medium-priority items above low-priority items and allowing maintainers to reorder items in “To do,” “In progress,” and “Needs review.”

• Nymius will inspect how LDK actually uses the trust_witness_utxo signing option and intends to return with a concrete answer the following day. He will also review the Rust Bitcoin PSBT implementation to determine which checks or compatibility behavior are needed.

• Nymius plans to focus during the coming week on the Rust-related PSBT/payment pull request while he has available attention, alongside the signer investigation.

• The signer work will be documented in an issue if no suitable issue already exists, including LDK’s expected behavior, BDK’s current safety checks, Rust Bitcoin PSBT behavior, and any necessary interim compatibility approach.

• Noah plans to turn summit insights into public discussions or issues and assign distinct owners where possible so that several maintainers do not independently investigate the same question.

• Steve will ask the summit group for permission to publish the raw notes, review them to remove names or sensitive attribution, and post them as an initial public record. He will also post screenshots from the separate in-person BDK roadmap discussion.

• Summit-derived feature requests will be converted into repository issues where issues do not already exist and tagged with the existing summit label. A central GitHub Discussion may hold the raw material and link to the resulting implementation issues.

• Rashit will keep his Esplora API pull request aligned with the outcome of the proposed API-standardization discussion among Mempool.space, Blockstream, and other Esplora implementers.

• Steve will contact or prod the Mempool.space team for information about its roadmap for agreeing on a standardized Esplora API, because the timing and outcome directly affect Rashit’s work.

• Matthew intends to digest the Rust Summit material and help turn it into issues, timelines, and milestones, with the goal of having the planning more fully developed by the end of the week.

• Steve will test the local, open-source “Anarlog” AI note-taking tool on this call and publish its output if useful. The intent is to make future discussions accessible to contributors who cannot attend live.

Blockers

• The BDK 4.0 signer decision remains unresolved. The team needs to confirm exactly how LDK uses trust_witness_utxo, whether both enabled and disabled modes must remain available, and whether Rust Bitcoin PSBT needs additional safety checks or only clearer documentation.

• BDK currently prefers the non-witness UTXO and applies additional safety guarantees, while the Rust Bitcoin PSBT path was described as accepting the witness UTXO without the same checks. Changing this default may introduce a security or compatibility concern and requires confirmation with the Rust Bitcoin team.

• Integrating Rust PSBT into BDK through BDK transaction components may take longer than the immediate Alpha 1 schedule. Nymius therefore suggested retaining an intermediate signer API compatible with LDK while providing the necessary checks, rather than migrating prematurely.

• The large number of bugs—many generated by LLM-based analysis—creates significant triage overhead. Reports vary in quality and priority, and maintainers need to prevent newcomers from spending time on low-value issues.

• Some open PRs and issues are waiting for feedback even though they are not currently high-maintainer priorities. Until milestones clearly identify active work, contributors cannot easily tell which changes are likely to receive timely review.

• Using both milestone membership and a separately ordered bug board risks duplicating prioritization work. The team agreed that ordering is useful, but it will require ongoing maintainer effort and must remain consistent with milestone decisions.

• Rashit’s Mempool.space/Esplora API work is partly blocked by uncertainty over whether Mempool.space, Blockstream, and other implementations will agree on a common API and when that standardization work will occur.

• Matt’s concern remains that supporting proprietary Mempool.space extensions could fragment the Esplora ecosystem and place maintenance responsibility on the community for a commercial service’s custom API. Steve countered that Mempool.space is popular with major wallet users and should be supported where practical.

• Several summit-derived requests may depend on broader architectural work. In particular, tracking foreign transactions may require multi-keychain support, and synchronization improvements need further scoping before they can be scheduled.

• The summit produced a large volume of feedback with no finalized publication location or issue breakdown. Until raw notes, discussions, and assigned issues are created, important requests could be lost or duplicated.

• Future agenda-led calls may occur at inconvenient times for many contributors. Notes and asynchronous GitHub discussions will be needed so absent participants can understand and influence decisions.

Team Updates

• The team supports using GitHub milestones as the primary roadmap. Each milestone should list the limited set of priority features, issues, and PRs that maintainers are actively targeting, making review priorities visible to contributors.

• Future developer-call agendas should be public rather than confined to Signal. A dated GitHub Discussion was favored because contributors can suggest topics in advance and directly link relevant issues and PRs; core maintainers will still select the final agenda and milestone contents.

• During calls, the facilitator could share the GitHub Discussion and work through its items directly, making it the working basis for weekly or biweekly developer meetings.

• Milestone scope will remain maintainer-driven to avoid an unmanageable consensus process, but the surrounding discussion and rationale should be public so the broader community can understand priorities and contribute input.

• The project-board bug workflow distinguishes untriaged reports from confirmed “To do” items, with additional “In progress” and “Needs review” columns. Maintainers can order items within those columns to communicate relative urgency.

• Small, confirmed bugs—such as removing unsafe unwraps or correcting edge-case logic—were identified as useful onboarding work. New contributors should be directed toward the prioritized list rather than the entire undifferentiated backlog.

• Thunderbiscuit proposed a first BDK 4.0 alpha milestone on an approximately eight-week horizon, with December 10 mentioned as the corresponding target date. Both Thunderbiscuit and Steve favored a shorter alpha cycle even if it contains fewer changes.

• Alpha releases are expected to be lightweight Git tags rather than crates.io releases, reducing the cost of releasing early and collecting feedback. The purpose is to narrow the active issue pool and create momentum around concrete integration points.

• The group discussed aiming for a quarterly release cadence for feature releases, while allowing bug-fix releases to occur more frequently. Steve cautioned that three months may be too aggressive for major breaking releases.

• The BDK 3.x line is expected to receive bug fixes rather than new features, while new feature development should target 4.0. Existing users such as LDK could remain on 3.2 while 4.0 alpha behavior and migration requirements are validated.

• No final decision was made to keep or remove wallet signing in BDK 4.0. Steve’s preference remains to remove signing from the wallet if Rust Bitcoin PSBT can provide or document the required behavior, while Thunderbiscuit emphasized that retaining signers longer would also be acceptable if downstream compatibility requires it.

• The team agreed not to avoid a justified breaking change solely because LDK currently depends on older behavior. A 4.0 release can change defaults when the new behavior is better for the general user base, provided downstream users receive clear feedback, migration guidance, and prominent release-note warnings.

• Nymius suggested maintaining an intermediate API compatible with LDK while the full Rust PSBT migration proceeds. A backport to the relevant Rust Bitcoin PSBT version may also be considered if needed.

• The signer investigation should cover every existing signing option, identify downstream users of each option, and determine whether it can be removed, replaced, or documented. The team noted that AI-assisted scans of large downstream codebases may accelerate this research.

• For Esplora, the current direction is to wait for progress toward a shared API among Mempool.space, Blockstream, and other implementers while continuing useful independent work. Steve reiterated that better support for existing Esplora users remains a priority.

• The existing summit label will be used for summit-derived issues instead of creating a year-specific label across every repository. A central Discussion can provide context and link to individually labeled implementation issues.

• The meeting was held on Discord, and additional discussions will continue through public GitHub artifacts, follow-up calls, and published notes rather than relying only on private messaging channels.

Transcribed and summarized by Anarlog

[oleonardolima]

In my opinion the iteration of 8-weeks for the 4.x.x-alpha.x versions seems reasonable, as (by the notes) they are not being aimed for a final crates-io release, though every one of them should be working smoothly in order to get user feedback.

I'd say that for final MAJOR releases the bold option would be every 6-month, though every 1-year is the safest option as we've been doing for the past years.

Also related to the releases and 8-week milestones the strategy I have in mind is keeping tracking issues for every major feature we'd like to have in 4.x.x releases, and use sub-issues for each single step or sub-feature we need. It's way better to have a single "big" tracking issue as the final goal where we can all refer to, and it's sub-issues for fine-grained discussions/work, then it all scattered all over the place.

[notmandatory]

For major features I like the idea of using tracking issues, github has a sub-issue feature we can use for these too.
https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues

This just helps link back to the parent issue, but has some limitations. It only works for prs/issues in the same repo and looks like you can only link them while they are still open. So already closed issues/prs and those in other repos will still need to be listed in the parent/tracking issue description. See bitcoindevkit/bdk_wallet#70.

After thinking about it more the way we're doing it now with check boxes in the description is easier to use.