wallet: enforce TRUC child weight for preset inputs #36463

A version 3 transaction that spends an unconfirmed wallet parent can be funded over the 4000 weight-unit child limit when the inputs are preset. Automatic coin selection already clamps that case. Preset inputs that cover the target skip the clamp. With add_inputs=true, a short unconfirmed preset can be topped up with confirmed coins, and those filters do not apply the clamp.

FetchSelectedInputs records the unconfirmed wallet parent. CreateTransactionInternal rejects the result with "Transaction too large" when the transaction is version 3 and the weight is over the child limit. The standard maximum-weight check is unchanged.

This edits the same size check as #36393. That change makes the check honor the caller's max weight. This one adds the 4000 weight-unit cap for an unconfirmed wallet parent. If #36393 merges first, this needs a rebase.

Preset inputs the wallet owns are covered. An output the wallet does not own takes the external path even when the wallet created its parent and knows that parent is unconfirmed. On this build that case funded at 5397 weight units, and testmempoolaccept rejected it. Inputs whose parent the wallet does not know stay out of scope.

sendall with explicit inputs is left out. sendall does not use CreateTransactionInternal. Its automatic path already lowers the limit to the child size. Its explicit-input path keeps the 40000 weight-unit limit, so an unconfirmed version 3 parent plus confirmed inputs can still be built over the child limit. On this build that case was 6327 weight units, and testmempoolaccept rejected it.

The same preset gap is on 32.x (2633a1ded5).

The new wallet_v3_txs.py cases cover four preset spends. An unconfirmed child over the child limit is rejected, and one under the limit funds. A confirmed version 3 preset over 4000 weight units still funds. add_inputs=true is rejected when a short unconfirmed preset is topped up past the child limit. The confirmed case is the one a check based on preset depth would have rejected, because those inputs are recorded with depth 0.

Tested with the 68 wallet functional tests and rpc_psbt.py, 74 runs including variants. wallet_backwards_compatibility.py, wallet_ancient_migration.py, and wallet_migration.py were skipped because they need previous releases.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

External sites

• Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36463
• Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36463.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36463#author-ralph

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

LLM Linter (✨ experimental)

Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

• test/functional/wallet_v3_txs.py: self.send_tx(self.charlie, [], {address: amount}, 3)
• test/functional/wallet_v3_txs.py: self.send_tx(self.charlie, [], {self.alice.getnewaddress(): 10}, 3)

^{2026-10-08 01:38:38}

To preserve the time of reviewers, this project requires authors to understand the code they are submitting. Given that the description is entirely LLM generated, I don't think that is the case, so I am closing this again.