psbt: fix PSBTInput::Merge ignoring sighash_type field #35217

PSBTInput::Merge (used by CombinePSBTs / combinepsbt RPC) did not handle the sighash_type (PSBT_IN_SIGHASH) field at all:

• When only the incoming PSBT had sighash_type set, the field was silently dropped from the merged result.
• When both PSBTs had conflicting sighash_type values, Merge returned true instead of false, violating BIP 174 combiner rule: 'If two PSBTs contain the same key and different values, the Combiner MUST reject the combined PSBT.'

Fix by copying the field when the receiving PSBT lacks it, and returning false on conflict.

Add six unit tests covering: both absent, copy from other, preserve existing, same value, and two conflict cases.

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35217.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

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

<!--5faf32d7da4f0f540f40219e4f7537a3-->

We prefer to test PSBT things with functional tests rather than unit tests.

We prefer to test PSBT things with functional tests rather than unit tests.

I moved it to a funcional test in test/funcional/rpc_psbt.py (test_combine_sighash_type)

Thanks, but LLM output is not accepted if the author can not properly explain, test or could have written the change themselves.

The bottleneck in this project has always been review and testing, not writing code. Development here is intentionally conservative and slow, and reviewer attention is the scarcest resource we have. LLMs have made this worse, anyone can now prompt them and post their output as PRs. There is an infinite amount plausible looking "improvements" for LLMs to suggest and work on.

Unless we fully trust LLMs to both write and review code, humans still have to spend time understanding the proposed changes, which incurs a non-zero cost for every opened PR.

I understand that contributing to this project can be intimidating, and using LLMs may seem tempting, but it really creates more issues for this project than it solves. The best way to help this project, is to review and test changes. You can use LLMs for this, but you shouldn't solely rely on them, or just post their output.

Please reconsider whether it's something you genuinely think the project should pursue, independent of what your LLM suggested.

I'll close this for now.