Parse the OP_RETURN push opcode instead of assuming OP_PUSHDATA1

[Chaitanya-Keyal]

Closes #963 and supersedes #965 and #1003. Both fix the same bug and can be closed once this lands. @ruipereira1 and @kwsantiago have been added as co-authors on the relevant commits.

Description

Problem or Issue being addressed

PSBTParser._parse_outputs() read the OP_RETURN payload at a fixed offset:

if self.psbt.tx.vout[i].script_pubkey.data[0] == OPCODES.OP_RETURN:
    # The data is written as: OP_RETURN + OP_PUSHDATA1 + len(payload) + payload
    self.op_return_data = self.psbt.tx.vout[i].script_pubkey.data[3:]

That comment is only true for payloads of 76 bytes and up. Script push opcodes are variable width:

encoding	prefix	used for
direct push (0x01-0x4b)	2 bytes	payloads up to 75 bytes
OP_PUSHDATA1	3 bytes	76 to 255 bytes
OP_PUSHDATA2	4 bytes	256 to 65535 bytes
OP_PUSHDATA4	6 bytes	larger

Bitcoin Core emits the shortest encoding that fits, so most real OP_RETURNs are a direct push and [3:] eats their first byte:

scriptPubKey:  6a 28 "Chancellor on the brink of third bailout"
parsed:           b'hancellor on the brink of third bailout'
expected:         b'Chancellor on the brink of third bailout'

Why the test suite did not catch it

Every existing fixture hard-coded OP_PUSHDATA1, the one encoding the parser assumed:

• tests/screenshot_generator/generator.py:85-89 concatenated it unconditionally. Its text payload is 50 bytes, which Core would push directly, so the screenshot was right for the wrong reason. Its other payload is 80 bytes, where OP_PUSHDATA1 really is minimal. No fixture ever produced a direct push.
• The regtest PSBT behind test_parse_op_return_content was built the same way: 2b 6a 4c 28 43 68 61 6e ....

Solution

Read the push opcode and slice to the length it declares, in a static PSBTParser._parse_op_return_payload() helper instead of inline in the loop. All four encodings are handled.

Two judgement calls, both explained in the docstring:

• Multiple pushes are concatenated. Legal but unusual. The user is approving the data the transaction commits to, and push boundaries have no consensus meaning or display convention.
• Malformed scripts show their bytes rather than nothing. If a byte is not a data push, or a push overruns the script, the walk stops and the rest is appended as-is. Returning b"" would hide committed data from a review screen.

Also fixed on the same lines:

• op_return_data is reset in _parse_outputs. It was only set in __init__, so re-parsing an instance kept a stale payload.
• The leading byte is compared by slice, so an empty scriptPubKey returns b"" instead of raising IndexError.

Additional Information

Left for a follow-up PR (#1043), to keep this one to a single change. None of these depend on push encoding; they are separate defects in the same area:

• Multiple OP_RETURN outputs collapse to the last one, since op_return_data is one bytes the loop overwrites. Core v30 dropped the one-per-transaction relay limit.
• An OP_RETURN's value is added to no total, so the overview's inputs = spend + change + fee does not balance when sats are burned on one.
• PSBTOpReturnScreen draws the whole payload into one unbounded TextArea. Not just cosmetic: it reflows the entire payload before drawing anything, at quadratic cost. 1 KB takes 83ms, 4 KB takes 1.2s, 16 KB takes 15.8s on a dev machine, and the device is much slower. At Core's new default carrier size the screen is effectively unreachable.

Screenshots

No new or modified screens, however the existing screenshot receives the correct bytes now.

---

This pull request is categorized as a:

• Bug fix

---

Checklist

I ran pytest locally

• All tests passed before submitting the PR

---

I included screenshots of any new or modified screens

• N/A

---

I added or updated tests

• Yes

---

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

Tested with my fork of Keith's testqrs.com (kdmukAI-bot/btc-datagen#2)

• Raspberry Pi OS Manual Build
• 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