bump_fee_rbf refuses to replace channel funding transactions by checking the payment record's tx_type. That check trusts the record, and the record can be missing the funding type at the moment of the call:
- A record wallet sync creates for a mempool transaction has
tx_type: None (see the TODO in create_payment_from_tx). If sync sees an interactive funding transaction before classification records it — the counterparty can broadcast as soon as signatures are exchanged, and classification can be delayed by a failing store — the untyped record passes the check. - Rejecting
tx_type: None outright isn't an option, because it's also the permanent state of every regular send: send_to_address doesn't write a record; sync creates it untyped.
Today the damage is limited. The only interactive funding transactions are splices, and a splice replacement would have to spend the channel funding outpoint, which isn't a wallet UTXO — BDK fails the bump before anything is signed, broadcast, or written. So a bump on an untyped funding record produces a confusing error rather than a double spend.
That stops holding if V2 dual-funded channel opens land: for an open where we contribute all the inputs, every input is a wallet UTXO, so the bump would build, sign, and broadcast a replacement of a negotiated funding transaction — a txid LDK isn't tracking — and record it as a regular send.
Proposed fix: check the txid against LDK's channel state at call time instead of trusting the record — ChannelDetails::funding_txo plus the splice candidate txids in ChannelDetails::splice_details. LDK knows a funding txid from signature exchange onward, before the transaction can appear in anyone's mempool, so this check can't go stale the way the record can. OnchainPayment::bump_fee_rbf already holds the ChannelManager for its anchor-reserve computation; the funding txids can be passed into the wallet method and checked after the record read. This is also what the existing TODO in create_payment_from_tx suggests (list_channels).
bump_fee_rbfrefuses to replace channel funding transactions by checking the payment record'stx_type. That check trusts the record, and the record can be missing the funding type at the moment of the call:tx_type: None(see the TODO increate_payment_from_tx). If sync sees an interactive funding transaction before classification records it — the counterparty can broadcast as soon as signatures are exchanged, and classification can be delayed by a failing store — the untyped record passes the check.tx_type: Noneoutright isn't an option, because it's also the permanent state of every regular send:send_to_addressdoesn't write a record; sync creates it untyped.Today the damage is limited. The only interactive funding transactions are splices, and a splice replacement would have to spend the channel funding outpoint, which isn't a wallet UTXO — BDK fails the bump before anything is signed, broadcast, or written. So a bump on an untyped funding record produces a confusing error rather than a double spend.
That stops holding if V2 dual-funded channel opens land: for an open where we contribute all the inputs, every input is a wallet UTXO, so the bump would build, sign, and broadcast a replacement of a negotiated funding transaction — a txid LDK isn't tracking — and record it as a regular send.
Proposed fix: check the txid against LDK's channel state at call time instead of trusting the record —
ChannelDetails::funding_txoplus the splice candidate txids inChannelDetails::splice_details. LDK knows a funding txid from signature exchange onward, before the transaction can appear in anyone's mempool, so this check can't go stale the way the record can.OnchainPayment::bump_fee_rbfalready holds theChannelManagerfor its anchor-reserve computation; the funding txids can be passed into the wallet method and checked after the record read. This is also what the existing TODO increate_payment_from_txsuggests (list_channels).