3.0 by reez · Pull Request #971 · bitcoindevkit/bdk-ffi

reez · 2026-03-11T19:32:55Z

Description

3.0 draft. WIP.

Notes to the reviewers

Documentation

Checklists

All Submissions:

I've signed all my commits
I followed the contribution guidelines
I ran cargo fmt and cargo clippy before committing
I've added a changelog in the next release tracking issue (see example)
I've linked the relevant upstream docs or specs above

New Features:

I've added tests for the new feature
I've added docs for the new feature

Bugfixes:

This pull request breaks the existing API
I've added tests to reproduce the issue which are now passing
I'm linking the issue being fixed by this PR

thunderbiscuit · 2026-03-11T19:39:16Z

🚀 🚀 🚀 🚀 🚀

reez · 2026-03-17T15:46:08Z

bitcoindevkit/bdk-kyoto#155 I opened this Draft PR (and a related issue)

Just using my fork of bdk-kyoto with the change rn

reez · 2026-04-13T16:08:18Z

updated to official 3.0

rustaceanrob · 2026-04-14T10:20:28Z

bdk_kyoto = 0.16.0 is out and includes the 3.0.0 release

reez · 2026-04-14T15:39:54Z

bdk_kyoto = 0.16.0 is out and includes the 3.0.0 release

thanks I updated to 0.16.0 and made one small change update_rx: Mutex<UpdateSubscriber<bdk_kyoto::wallets::Single>> necessary along with it in 27be17f

thunderbiscuit

I compiled and ran Rust tests locally today. Just started looking at this and left a few comments. I haven't gone through all files yet (tx_builder, types, wallet left to do). I'll try and migrate the Android app to this potential alpha to see how the migration goes! Looks like it should be pretty smooth.

thunderbiscuit · 2026-04-15T18:51:28Z

 [package]
 name = "bdk-ffi"
-version = "2.4.0-alpha.0"
+version = "3.0.0"


This one here I think should read 3.0.0-alpha.0 since this would merge on master.

Ahhh, I guess I did no -alpha just because in my head I was thinking we only bumped to -alpha after the release work was merged to master and the release was cut, but I might have been remembering that wrong.

No strong opinion from me, just wanted to double check w ya, but im good with whatever you comment back on this for me to change it to.

(go w thunders suggestion here)

updated w commit 061266b

thunderbiscuit · 2026-04-15T18:56:37Z

        let secp = Secp256k1::new();
-        let (extended_descriptor, key_map) = descriptor.into_wallet_descriptor(&secp, network)?;
+        let (extended_descriptor, key_map) =
+            descriptor.into_wallet_descriptor(&secp, network.into())?;


I still need to get to grips with the NetworkKind type. Are there situations where we'd like to use that instead of the Network for example? Not sure.

I don’t have any concrete ffi facing cases that come to mind, since NetworkKind only has Main and Test... I’ve been thinking of it as mostly an internal/upstream type for apis that only care about that distinction, where bdk-ffi consumers would usually want the full Network to preserve the actual chain. But I need to keep thinking about it more too so im glad you commented on it here

thunderbiscuit · 2026-04-15T19:05:23Z

+#[derive(Debug, Clone, uniffi::Record)]
+pub struct PreV1WalletKeychain {
+    /// The wallet keychain.
+    pub keychain: bdk_wallet::KeychainKind,


Can we use our own KeychainKind from the types module here? I think they're functionally equivalent because it's using remote enums in uniffi, but could still be a tiny cleanup unless I am missing something.

I think the small uniffi wrinkle i found here was crate::types::KeychainKind isn’t currently usable from this module because the backing alias in types.rs is private so switching this line wasn't a easy one line cleanup, and since the rest of the code was also using bdk_wallet::KeychainKind directly I decided to leave it as is in this PR.

But its definitely something we could do, it just seemed like it might end up needing to be a separate/bigger refactor

thunderbiscuit · 2026-04-15T19:06:34Z

    }
+
+    /// Retrieve keychain metadata from a pre-v1 BDK SQLite wallet database.
+    pub fn get_pre_v1_wallet_keychains(


I'd love to see a test for this one in the Android or Swift parts of the codebase if possible.

Yeah, that makes sense. I looked around the code and I think we already have Swift/Android persistence tests but I don’t think we had a pre-v1 SQLite database in the repo, so adding a bindings test for this I think would have meant adding that first. And then also I wasn't totally sure if we were going to expose this in 3.0 or not.

But im with you on if we do want to expose this for sure in our ffi 3.0 (or whenever we expose it in a release) that it would be quite nice to have a test for this, and prob worth putting in time to figure out how to test it well

thunderbiscuit · 2026-04-15T19:09:50Z


+/// Metadata describing a keychain in a pre-v1 BDK SQLite wallet database.
+#[derive(Debug, Clone, uniffi::Record)]
+pub struct PreV1WalletKeychain {


I was looking at the Rust code for this type and I see that the API docs have changed since you added it I think. See here.

this is deep in the weeds, I love it, good catch!

updated in 6cca30e

reez · 2026-04-20T17:20:57Z

@thunderbiscuit I rebased onto current master and dropped commits superseded by #978

github-project-automation Bot added this to BDK-Bindings Mar 11, 2026

reez changed the title ~~(DRAFT) Rc1~~ (DRAFT) 3.0 Rc1 Mar 11, 2026

reez changed the title ~~(DRAFT) 3.0 Rc1~~ (DRAFT) 3.0 RC's Mar 27, 2026

reez linked an issue Mar 30, 2026 that may be closed by this pull request

bdk_wallet 3.0 #869

Open

reez changed the title ~~(DRAFT) 3.0 RC's~~ (DRAFT) 3.0 Apr 14, 2026

thunderbiscuit reviewed Apr 15, 2026

View reviewed changes

reez mentioned this pull request Apr 16, 2026

chore: bump bdk_wallet 3.0.0 and bdk_kyoto 0.16.0 #978

Merged

14 tasks

reez added 10 commits April 20, 2026 12:07

feat(wallet): expose apply_unconfirmed_txs_events

b7e9953

feat(wallet): expose apply_evicted_txs_events

f515e56

feat(wallet): expose checkpoints

7fd91ce

feat(wallet): expose start_sync_with_revealed_spks_at

0e2dad8

feat(wallet): expose start_full_scan_at

2fbe49c

feat(tx-builder): expose sighash

41192ce

feat(tx-builder): expose add_foreign_utxo_with_sequence

dc58766

feat(tx-builder): expose ordering

ef860bf

feat(wallet): expose locked outpoints and persist them in changesets

2c4b2c7

feat(store): expose pre-v1 sqlite migration helper

df64127

reez force-pushed the rc1 branch from 061266b to df64127 Compare April 20, 2026 17:19

reez changed the title ~~(DRAFT) 3.0~~ 3.0 Apr 20, 2026

reez marked this pull request as ready for review April 20, 2026 17:19

Conversation

reez commented Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Notes to the reviewers

Documentation

Checklists

All Submissions:

New Features:

Bugfixes:

Uh oh!

thunderbiscuit commented Mar 11, 2026

Uh oh!

reez commented Mar 17, 2026

Uh oh!

reez commented Apr 13, 2026

Uh oh!

rustaceanrob commented Apr 14, 2026

Uh oh!

reez commented Apr 14, 2026

Uh oh!

thunderbiscuit left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reez commented Apr 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

reez commented Mar 11, 2026 •

edited

Loading