Note this breaks the existing inputs' format, but can trivially be fixed:

for f in ./psbt/*; do echo "$f" && sed -i 's|\\|\\\\|g' "$f"; done

@practicalswift Thomas J, mind taking a look here? This only changes the fuzz target you added, so shouldn't be too hard to review.

@MarcoFalke Sure! Thanks for the ping!

Tested ACK faaf395

FWIW I believe the code paths that this PR adds coverage for is a subset of the code paths covered by the RPC fuzzer (see #21169). That is just an observation and not an argument against this PR.

I think we should strive for covering our functions both 1.) from the "micro level" as in this case, and 2.) from the "macro level" as in the case of say the process_message, process_messages and rpc fuzzers.

Why?

1. The macro level harnesses are more constrained and the fuzzer will thus focus its finite resources on realistic code paths which may be problematic as the code is written today ("reachable" bugs).
2. The micro level harnesses give the fuzzer permission to explore also code paths which are not exercised by current callers but may be exercised in the future by future callers (currently "unreachable" latent bugs).

In other words: Strong Concept ACK for reaching into the PSBT code from both the micro level (this PR) and from the macro level (RPC fuzzer, see #21169) :)