[sanity check] Reject a PSBT whose fingerprint records disagree

[kdmukai]

Builds on top of changes in #1044. Kept in DRAFT until its parent is merged.

This is a LOW priority follow-up to the _get_cosigners change in #1032 (45a5eab), which stopped using the claimed fingerprint to match a key to its xpub. It occurred to me that while we can't rely on the fingerprints being correct from the coordinator, we can verify that they're at least internally consistent when supplied (global xpubs' fingerprints match the fingerprint for the key that they derive).

Written by Claude, revised by Keith:

---

Description

Problem or Issue being addressed

A psbt carries two claims about each key's origin:

• the fingerprint on the key's derivation path entry (bip32_derivations)
• the fingerprint on the global xpub that derives that key (PSBT_GLOBAL_XPUB)

Both are the coordinator's own claims about the same master key, so they should agree. Currently a psbt where they disagree parses without complaint: since #1032 matches keys to xpubs by derivation, a mislabeled fingerprint would be completely ignored.

There's no attack risk in allowing mismatched fingerprints: cosigners resolve by derivation, and a mislabel on a cosigner's key changes nothing downstream (though a mislabel that claims OUR fingerprint is already caught by the ownership scan).

It's evidence of a self-contradictory psbt and we already reject psbts for similar correctness issues without calling them attacks (PSBTMixedDerivationPathTypesError, the single-sig case of PSBTSurplusDerivationPathsError).

---

Solution

A new final step in parse(), _reject_inconsistent_fingerprints, iterates through every input and output entry, finds the global xpub that derives its key (through the existing derivation cache, so the re-derivation is basically free), and raises PSBTInconsistentFingerprintError if the two fingerprints differ.

• All-zero fingerprints are skipped on either side. Coordinators write 00000000 for a fingerprint they do not know (xpub-only keystores; see _fill_missing_fingerprints), so that is a missing value, not a second answer.
• Runs last so that a more serious finding about our own keys (PSBTOutputOwnershipContradictionError, the ownership claim errors) is still the one reported.

The view layer routes the new error to PSBTInconsistentFingerprintView, a Warning-level "Transaction Problem" screen in the same grade as the mixed-derivation-map error: one record is wrong, but nothing says which, so it is not graded as an attack.

---

Additional Information

• _get_cosigners is where the two records meet and would be the natural place for the check, but it is a static helper under _get_policy's catch-all except, and raising there would pre-empt the more serious errors that run later. A TODO on the new method records the refactor (instance methods, record the mismatch, raise after the outputs are read).
• Also in this PR: a TODO in mnemonic_generation.py for a seed whose real fingerprint is 00000000. Such a seed cannot be told apart from one the coordinator never identified, so a multisig psbt that also carries zero-labeled cosigner keys is refused for it. One seed in 2^32; no code change.

---

Tests

• New tests added for single sig and multisig fingerprint mismatch scenarios, including the all-zero case.
• Minor changes to affected existing tests.

---

Screenshots

---

This pull request is categorized as a:

• Other: Insist on internal consistency in psbt claims.

---

Checklist

I ran pytest locally

• All tests passed before submitting the PR

---

I included screenshots of any new or modified screens

Should be part of the PR description above.

• Yes

---

I added or updated tests

Any new or altered functionality should be covered in a unit test. Any new or updated sequences require FlowTests.

• Yes

---

I tested this PR hands-on on the following platform(s):

• SeedSigner OS on a Pi0/Pi0W board

---

I have reviewed these notes:

• Keep your changes limited in scope.
• If you uncover other issues or improvements along the way, ideally submit those as a separate PR.
• The more complicated the PR, the harder it is to review, test, and merge.
• We appreciate your efforts, but we're a small team of volunteers so PR review can be a very slow process.
• Please only "@" mention a contributor if their input is truly needed to enable further progress.

• I understand

---

Thank you! Please join our Devs' Telegram group to get more involved.