Skip to content

Update bdk_kyoto to 0.17.0 on 3.0.0 release branch #996

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
thunderbiscuit merged 1 commit into from
May 12, 2026
Merged

Update bdk_kyoto to 0.17.0 on 3.0.0 release branch #996

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions bdk-ffi/Cargo.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion bdk-ffi/Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ path = "uniffi-bindgen.rs"
bdk_wallet = { version = "=3.0.0", features = ["all-keys", "keys-bip39", "rusqlite"] }
bdk_esplora = { version = "0.22.1", default-features = false, features = ["std", "blocking", "blocking-https-rustls"] }
bdk_electrum = { version = "0.23.2", default-features = false, features = ["use-rustls-ring"] }
bdk_kyoto = { version = "0.16.0" }
bdk_kyoto = { version = "0.17.0" }

uniffi = { version = "=0.30.0", features = ["cli"]}
thiserror = "2.0.17"
Expand Down
17 changes: 9 additions & 8 deletions bdk-ffi/src/kyoto.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
use bdk_kyoto::bip157;
use bdk_kyoto::bip157::lookup_host;
use bdk_kyoto::bip157::tokio;
use bdk_kyoto::bip157::AddrV2;
Expand All @@ -6,7 +7,7 @@ use bdk_kyoto::bip157::Node;
use bdk_kyoto::bip157::ServiceFlags;
use bdk_kyoto::builder::Builder as BDKCbfBuilder;
use bdk_kyoto::builder::BuilderExt;
use bdk_kyoto::HeaderCheckpoint;
use bdk_kyoto::HashCheckpoint;
use bdk_kyoto::Receiver;
use bdk_kyoto::RejectReason;
use bdk_kyoto::Requester;
Expand Down Expand Up @@ -196,25 +197,25 @@ impl CbfBuilder {
if !matches!(network, Network::Bitcoin) {
bdk_kyoto::ScanType::Recovery {
used_script_index,
checkpoint: HeaderCheckpoint::from_genesis(network),
checkpoint: HashCheckpoint::from_genesis(network),
}
} else {
match checkpoint {
RecoveryPoint::GenesisBlock => bdk_kyoto::ScanType::Recovery {
used_script_index,
checkpoint: HeaderCheckpoint::from_genesis(wallet.network()),
checkpoint: HashCheckpoint::from_genesis(wallet.network()),
},
RecoveryPoint::SegwitActivation => bdk_kyoto::ScanType::Recovery {
used_script_index,
checkpoint: HeaderCheckpoint::segwit_activation(),
checkpoint: HashCheckpoint::segwit_activation(),
},
RecoveryPoint::TaprootActivation => bdk_kyoto::ScanType::Recovery {
used_script_index,
checkpoint: HeaderCheckpoint::taproot_activation(),
checkpoint: HashCheckpoint::taproot_activation(),
},
RecoveryPoint::Other { birthday } => bdk_kyoto::ScanType::Recovery {
used_script_index,
checkpoint: HeaderCheckpoint::new(birthday.height, birthday.hash.0),
checkpoint: HashCheckpoint::new(birthday.height, birthday.hash.0),
},
}
}
Expand Down Expand Up @@ -302,9 +303,9 @@ impl CbfClient {

/// Broadcast a transaction to the network, erroring if the node has stopped running.
pub async fn broadcast(&self, transaction: &Transaction) -> Result<Arc<Wtxid>, CbfError> {
Copy link
Copy Markdown
Member

@thunderbiscuit thunderbiscuit May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the method is submit_package on the client, we might want to call it that here as well. I know we've had these issues with the Esplora and Electrum clients before where the naming is not standardized, and sticking to the clients API naming is what we have done in the past.

Copy link
Copy Markdown
Member

@thunderbiscuit thunderbiscuit May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In any case this is 3.0 so it's the right time to break the API if we want to. I'm not leaning one way or another in this case; @rustaceanrob what you do you think?

Copy link
Copy Markdown
Collaborator Author

@rustaceanrob rustaceanrob May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we change the name I would prefer to roll out the full CPFP API around it, as in we implement a one-parent-one-child type and allow it to be submitted here. I don't think I would have that ready in time for 3.0.0 nor do I think its very pressing for FFI. broadcast_tx is a better description at the moment IMO

Copy link
Copy Markdown
Member

@thunderbiscuit thunderbiscuit May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right let's do that then.

let tx = transaction.into();
let tx: bip157::Transaction = transaction.into();
self.sender
.broadcast_tx(tx)
.submit_package(tx)
.await
.map_err(From::from)
.map(|wtxid| Arc::new(Wtxid(wtxid)))
Expand Down
Loading