`direct_conflicts` should guarantee ordering with most recent conflict last

[Camillarhi]

Describe the enhancement
The TxGraph::direct_conflicts() method returns a Vec<(usize, Txid)> of conflicting transactions, but there's currently no guaranteed ordering. For downstream libraries like bdk-wallet that need to track transaction replacements (RBF, double-spends), it would be helpful if the ordering was guaranteed such that the last entry is always the most recent/canonical transaction that remains in the mempool.

Use case
When generating wallet events for replaced transactions in bdk-wallet, we need to identify which conflicting transaction actually replaced the original one. I'm currently using bdk-wallet in ldk-node and consuming these events, but without guaranteed ordering from direct_conflicts(), there's no reliable way to determine which conflict is the canonical replacement.

Impact

• Blocking production usage
• Nice-to-have / UX improvement
• Developer experience / maintainability

Are you using BDK in a production project?

• Yes
• No
• Not yet, but planning to

Which backend(s) are relevant (if any)?

• Electrum
• Esplora
• Bitcoin Core RPC
• None / not backend-related (e.g. bdk_chain, bdk_core)
• Other (please specify): ____

Project or organization (optional)

Additional context
This came up while implementing wallet events (specifically TxReplaced events) in bdk-wallet. Related PR: lightningdevkit/ldk-node#628

[evanlinjin]

Note that TxGraph::direct_conficts returns all conflicts (not just canonical ones). Changing this method to be aware of canonicalization would NOT make sense as TxGraph should not be aware of canonicalization (separation of concern).

Reading through this ticket, my understanding is your requirement is to have a convenient way to get the canonical replacements ordered by confirmation status. Is this a fair assessment?

Which version of bdk_chain are you using?

[Camillarhi]

Note that TxGraph::direct_conficts returns all conflicts (not just canonical ones). Changing this method to be aware of canonicalization would NOT make sense as TxGraph should not be aware of canonicalization (separation of concern).

Reading through this ticket, my understanding is your requirement is to have a convenient way to get the canonical replacements ordered by confirmation status. Is this a fair assessment?

Hey, thanks for the reply!
So I don’t actually need them ordered by confirmation status exactly. What I’m after is more like, if tx_a got replaced by tx_b, and tx_b got replaced by tx_c, I’d want [tx_a, tx_b, tx_c] back, where tx_c is last, Basically just replacement order

Which version of bdk_chain are you using?

I’m on bdk_wallet v2.3 via ldk-node, not using bdk_chain directly.