Please describe the feature you'd like to see added.
Extend the PSBT-oriented RPCs utxoupdatepsbt and descriptorprocesspsbt with an optional prevtxs array parameter. Each entry is the raw hex of a parent transaction that the caller already knows about but which is not yet in the UTXO set, transaction index, or mempool. When populating PSBT input data (witness UTXOs, non-witness UTXOs, etc.), the node would consult the caller-supplied transactions first, then fall back to the txindex and mempool as it does today.
This mirrors the long-standing prevtxs argument on signrawtransactionwithwallet / signrawtransactionwithkey, bringing the PSBT workflow to feature parity with the legacy raw-transaction workflow.
Is your feature related to a problem, if so please describe it.
When constructing presigned transaction chains — e.g. Lightning commitment transactions, anchor spends, CPFP packages, or any multi-stage protocol that builds children before parents are broadcast — the child PSBT cannot be completed by utxoupdatepsbt or descriptorprocesspsbt. These RPCs only look up previous outputs in sources the node already tracks (UTXO set, txindex, mempool). Because the parent has never been broadcast, none of those sources contain it, so the RPCs return the PSBT unchanged and the caller has no way to fill in the required witness/non-witness UTXO fields through the standard PSBT API.
Today the only workarounds are:
- Abandon the PSBT workflow and fall back to
signrawtransactionwithwallet, which already acceptsprevtxsbut is considered the legacy path. - Manually serialize / splice the required fields into the PSBT outside of Bitcoin Core.
Both options are awkward and inconsistent with the rest of the PSBT tooling.
Describe the solution you'd like
Add an optional prevtxs array parameter to both RPCs, accepting raw transaction hex strings, e.g.:
utxoupdatepsbt "psbt" ( ["descriptor", ...] ["rawtx_hex", ...] )
descriptorprocesspsbt "psbt" ["descriptor", ...] ( "sighashtype" bip32derivs finalize ["rawtx_hex", ...] )
Behavior:
- Each entry is decoded into a
CTransactionand indexed by txid. - During PSBT input processing, the caller-supplied map is consulted first, before falling back to txindex and mempool.
- Duplicate txids inside
prevtxsproduce an explicit RPC error rather than silently overwriting. - Invalid hex / undecodable transactions produce a clear RPC error.
- The parameter is optional and fully backwards compatible — existing callers are unaffected.
Describe any alternatives you've considered
- Document the
signrawtransactionwithwalletfallback. Rejected — it doesn't solve the problem for watch-only / hardware-signer flows that are specifically designed around PSBT, and it fragments the user-facing RPC surface. - Broadcast the parent first so it lands in the mempool. Rejected — the whole point of presigned chains is that the parent must not be broadcast before the child is fully constructed and signed.
- Have callers patch the PSBT binary themselves (splicing witness/non-witness UTXO records client-side). Rejected — duplicates serialization logic that already lives in Core and is error-prone.
- A new dedicated RPC (e.g.
psbtaddprevtxs). Rejected — the functionality is a strict superset of whatutxoupdatepsbt/descriptorprocesspsbtalready do; adding a parameter is less surface area and matches the precedent set bysignrawtransactionwithwallet.