feat: expose tx_details

[reez]

Description

Builds on #777 (will rebase once merged)

Notes to the reviewers

Changelog notice

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

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

[Copilot]

Pull Request Overview

Adds a new FFI method to retrieve detailed transaction information from the wallet, defines the corresponding record type, and updates dependencies/imports to align with bdk-wallet v2.

• Introduces tx_details in Wallet and a new TxDetails record in types
• Updates several From implementations and error mappings to handle new fields
• Bumps BDK dependencies to v2.0.0-beta and removes bdk-core

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
bdk-ffi/src/wallet.rs	Added tx_details method to expose transaction details
bdk-ffi/src/types.rs	Defined new TxDetails record and updated import paths
bdk-ffi/src/error.rs	Extended error mapping for InvalidOutputIndex
bdk-ffi/src/electrum.rs	Adjusted imports and replaced unwrap target for blockhash
bdk-ffi/Cargo.toml	Bumped BDK dependencies to 2.0.0-beta versions

Comments suppressed due to low confidence (3)

bdk-ffi/src/wallet.rs:423

• Add unit tests for the new tx_details method to cover both existing and missing transaction scenarios.

pub fn tx_details(&self, txid: Arc<Txid>) -> Option<crate::types::TxDetails> {

bdk-ffi/src/types.rs:971

• Missing documentation comments for TxDetails and its fields; consider adding explanations for each field.

pub struct TxDetails {

bdk-ffi/src/types.rs:989

• [nitpick] Casting fee rate to f32 may lose precision; consider using f64 or documenting the rounding behavior explicitly.

fee_rate: details.fee_rate.map(|fr| fr.to_sat_per_vb_ceil() as f32),

[reez]

Tested locally built swift bindings

[ItoroD]

This is great! I ran the kotlin test too. All good!

Do we want to add like a print out for tx_details in the test. Somewhere like testSyncedBalance() in LiveTransactionTests already has some printouts. That would be a good place. (Its not key, but just a plus)

Side note: I printed out tx_details in kotlin and noticed Amount and Transaction were printing the object address. We might want to implement display for those? Let me know if to go ahead.

[reez]

This is great! I ran the kotlin test too. All good!

Do we want to add like a print out for tx_details in the test. Somewhere like testSyncedBalance() in LiveTransactionTests already has some printouts. That would be a good place. (Its not key, but just a plus)

Side note: I printed out tx_details in kotlin and noticed Amount and Transaction were printing the object address. We might want to implement display for those? Let me know if to go ahead.

Great suggestion about possibly adding the print statements for tx_details. I implemented this across platforms and ran into some interesting findings around Display vs Debug traits. Initially I tried implementing Display trait for Amount and Transaction objects to get better string representations. While Amount implements Display, Transaction only implements Debug, Clone, Eq, Hash, and serialization traits. This means we'd need manual Display implementations for Transaction; I wasn’t necessarily loving that if the context was just adding print statements for our tests at the moment.

Instead, I decided to go with #[uniffi::export(Debug)] since both underlying types already have Debug derived, requiring zero manual implementation. The Debug approach worked great for Swift but revealed a possible UniFFI inconsistency with Kotlin:

Swift

  Transaction details: Optional(BitcoinDevKit.TxDetails(
    txid:
  5509a011fca8c2764330d1c5268f9f4822f89e9479740bc1df943cb675b1bb0c,
    sent: Amount(6608 SAT),           
    received: Amount(2127 SAT),       
    fee: Optional(Amount(281 SAT)),   
    feeRate: Optional(2.0),
    balanceDelta: -4481,
    chainPosition: BitcoinDevKit.ChainPosition.confirmed(...),
    tx: Transaction(...)             
  ))

Kotlin (Still Memory Addresses)

  Transaction details: TxDetails(

  txid=5509a011fca8c2764330d1c5268f9f4822f89e9479740bc1df943cb675b1bb0c,
    sent=org.bitcoindevkit.Amount@30af5b6b,     
    received=org.bitcoindevkit.Amount@19835e64,   
    fee=org.bitcoindevkit.Amount@68b32e3e,      
    feeRate=2.0,
    balanceDelta=-4481,
    chainPosition=Confirmed(...),
    tx=org.bitcoindevkit.Transaction@63787180   
  )

UniFFI generates debugDescription properties for Swift when using #[uniffi::export(Debug)], but doesn't generate toString() methods for Kotlin - it only does that for Display trait. The debug functions exist in the Kotlin bindings but are never called? This seems like a possible UniFFI bug/inconsistency that I'm documenting and might open up an Issue on the uniffi repo asking about it.

Anyway, I'm leaning toward not adding the print statements in this PR and instead including them as part of the larger API ergonomics discussion in #769 because it feels like it deserves proper cross-platform consideration considering some of what I ran into which didn’t allow things to be as simple/elegant as possible. That said, I'm totally open to adding the print statements here if you prefer! And I'm happy to keep the #[uniffi::export(Debug)] since it's simple and does improve the Swift experience, even if Kotlin still shows memory addresses. What do you think? Should we focus this PR on just the tx_details exposure (and us both having tested the code and locally built bindings), or add the printing with the caveat that Kotlin might not be be as pretty until we solve the potentially underlying UniFFI inconsistency?

[ItoroD]

at for Display trait. The debug functions exist in the Kotlin bindings but are never called? This seems like a possible UniFFI bug/inconsistency that I'm documenting and might open up an Issue on the uniffi repo asking about it.

Thanks for this! Kotlin does not have the "debugDescription" concept like swift has. I can imagine that's why its still printing object addresses. Are printing in swift using the debugPrint() in swift to get the complete output? or even regular print gives the complete description? (No addresses) Debug should definitely be kept! no reason to remove that. 👍

Anyway, I'm leaning toward not adding the print statements in this PR and instead including them as part of the larger API ergonomics discussion in #769 because it feels like it deserves proper cross-platform consideration considering some of what I ran into which didn’t allow things to be as simple/elegant as possible.

Ok, that's fine.

I do agree that this PR should just focus on exposing tx_details which I think has been nicely done.

[reez]

at for Display trait. The debug functions exist in the Kotlin bindings but are never called? This seems like a possible UniFFI bug/inconsistency that I'm documenting and might open up an Issue on the uniffi repo asking about it.

Thanks for this! Kotlin does not have the "debugDescription" concept like swift has. I can imagine that's why its still printing object addresses. Are printing in swift using the debugPrint() in swift to get the complete output? or even regular print gives the complete description? (No addresses) Debug should definitely be kept! no reason to remove that. 👍

Anyway, I'm leaning toward not adding the print statements in this PR and instead including them as part of the larger API ergonomics discussion in #769 because it feels like it deserves proper cross-platform consideration considering some of what I ran into which didn’t allow things to be as simple/elegant as possible.

Ok, that's fine.

I do agree that this PR should just focus on exposing tx_details which I think has been nicely done.

Cool, appreciate your initial questions because they led me down a pretty interesting rabbit hole!

[reez]

rebased