OP_RETURN output poisons duplicate detector and rejects the next transaction

[BitHighlander]

Target

BitHighlander/keepkey-firmware, firmware 7.14.3 Bitcoin-only + Dice audit. The affected signing code is shared with the full product.

Finding

Signing a transaction whose final output is OP_RETURN poisons the duplicate-transaction detector. The next legitimate transaction with a normal payment output is refused with the on-device warning WARNING: Duplicate Transaction! and the protocol returns (Failure_ActionCancelled, "Transaction cancelled").

This is fail-safe (refusal, not an unauthorized signature), but every OP_RETURN-terminated THORChain/Maya-style transaction can arm the denial until power cycle.

Root cause

STAGE_REQUEST_3_OUTPUT calls txin_dgst_final() once for every output. A normal confirmed address output calls txin_dgst_save_and_reset(), but compile_output() returns early for PAYTOOPRETURN without resetting. When OP_RETURN is the last output, the SHA-256 context is left finalized. The next transaction hashes inputs into that finalized context, producing a different digest while amount/address can match the previous payment output—the exact predicate that triggers the warning.

Reproduction / regression evidence

The new Docker Bitcoin-only product suite performs, in one emulator session:

1. sign a payment + OP_RETURN transaction;
2. sign a legitimate payment transaction;
3. observe review codes [ConfirmOutput, Other] and cancellation on the second signing.

Control: the same payment transaction signs twice when no OP_RETURN transaction precedes it.

JUnit result: test_msg_bitcoin_only_variant.py::TestBitcoinOnlyVariant::test_op_return_does_not_poison_the_duplicate_detector is the sole failure after the other Bitcoin-only boundary defects were corrected (252 passed, 415 variant/version skips).

Expected fix

Finalize the input digest once, after input collection and before output review begins—not once per output. Preserve the existing save/reset after the confirmed payment output. Gate with the cross-transaction regression above plus native and full-product signing suites.

[BitHighlander]

Auditor correction after full-suite counterexample

The proposed “finalize once after input collection” fix is not correct for
this legacy detector. The full Bitcoin-only product suite caught that it
changes the detector's per-output lifecycle: both
test_msg_signtx.py::test_lots_of_outputs and the raw equivalent unexpectedly
prompted at output index 2. That candidate fix was rejected before publication.

The corrected boundary is transaction start:

• retain the existing txin_dgst_final() before each output, because each
  confirmed payment output saves/resets the digest and its amount/address;
• add txin_dgst_reset_current() and call it from signing_init() so an
  OP_RETURN-only/final-output path cannot carry a finalized SHA-256 context into
  a later transaction;
• preserve txin_last_digest, amount, and address so the intended cross-request
  duplicate warning still operates.

The final gate must pass the OP_RETURN cross-transaction regression, the
same-transaction control, and both many-output regressions together.

[BitHighlander]

Corrected resolution is in fork PR #604 at exact head 1d446ccbc9cf32a6e499990e65bcf7b358f1325b. The current signing digest is reset at the signing boundary while the prior completed-transaction digest used by the duplicate warning is preserved. The rejected first remediation and its many-output failures remain recorded above as auditor-of-auditor evidence. Exact-head Bitcoin-only product lane: 253 passed, 415 skipped, 0 failed; https://github.com/BitHighlander/keepkey-firmware/actions/runs/32945400323. This issue remains open until merge.