Thank you for working on this.

I do not think modifying the canonicalization is the right approach.

For example, if we have a min-confirmation-count of 3. We expect that a transaction confirmed at depth 2 should be prioritized over a transaction with no confirmations. With the current state of the PR, this guarantee is nonexistent.

Additionally, different min-confirmation-count values should not influence the Balance::total value. It should only shift values between *pending,immature,confirmed.

Idea 1

The simplest solution would be to not do any code changes and provide a doctest showing how we could manipulate the chain_tip input of TxGraph::[try_]balance. I.e. with LocalChain/CheckPoints.

let tip = chain.tip();

let target_height = tip.height().saturating_sub(confirmation_threshold);

let target_tip = tip
    .range(..=target_height)
    .next()
    .expect("checkpoint from local chain must have genesis");

// Use `target_tip` as the `chain_tip` input of `TxGraph::[try_]balance`.

For bdk_wallet::Wallet, we should probably provide a convenience method of sorts so the caller does not need to dig into the internal structures.

Idea 2

We can change the trust_predicate to be a more general predicate.

pub fn balance(
    /* Other Inputs */
    
    // predicate inputs: (txout_meta, txout, tip_height)
    mut predicate: impl FnMut(&OI, FullTxOut<A>, u32) -> BalanceType,
) -> Balance { todo!() }

// Maybe put this in `bdk_core`?
pub enum BalanceType {
    Immature,
    TrustedPending,
    UntrustedPending,
    Confirmed,
}

However, this is a breaking change and it makes it more involved to implement the predicate.

Let me know what you think.

ACK 657a044

ACK 657a044