Skip to content

feat: add output op_return get_bytes jets#339

Open
stringhandler wants to merge 1 commit into
BlockstreamResearch:masterfrom
stringhandler:feat/add-output-return-jets
Open

feat: add output op_return get_bytes jets#339
stringhandler wants to merge 1 commit into
BlockstreamResearch:masterfrom
stringhandler:feat/add-output-return-jets

Conversation

@stringhandler
Copy link
Copy Markdown

@stringhandler stringhandler commented Jun 3, 2026

Adds output_null_get_bytes_{1,2,4,8,16,32,64} jets for reading raw byte data from null-data (OP_RETURN) outputs, and the supporting OP_PUSHBYTES_* opcode variants that make them possible.

Background

Previously, output_null_datum could identify a push in a null-data script and return its SHA-256 hash, but there was no way for a Simplicity program to access the actual bytes. This matters for null-data outputs that carry small, fixed-size payloads (nonces, amounts, asset IDs, public keys, signatures) that a contract needs to inspect directly.

New jets (C/elements/elementsJets.c)

simplicity_output_null_get_bytes_{1,2,4,8,16,32,64} - each takes an output index and a push index and returns S (S TWO^N): nothing if the output isn't null-data, nothing if the indexed push isn't exactly N bytes, or the raw bytes.

Introduce OP_PUSHBYTES_1/2/4/8/16/32/64 variants for null-data push opcodes.
Unlike OP_IMMEDIATE, these variants store the raw pushed bytes inline in
opcode.data alongside the SHA-256 hash, allowing jets to access actual data
for fixed-size pushes (1, 2, 4, 8, 16, 32, 64 bytes).

parseNullData now maps byte-count pushes of those specific sizes to the
corresponding OP_PUSHBYTES_* code; output_null_datum encodes them as
OP_IMMEDIATE for wire compatibility.
@stringhandler stringhandler marked this pull request as ready for review June 3, 2026 13:37
@apoelstra
Copy link
Copy Markdown
Collaborator

We first need to develop some sort of versioning mechanism so that the Simplicity interpreter knows whether these jets are active or not. Directly enabling them like this would hardfork the Liquid network.

@stringhandler
Copy link
Copy Markdown
Author

Yeah, there is the version number in the tapleaf, but we may want to be sparing with version upgrades.

Do you think we need a version for BlockstreamResearch/rust-simplicity#345 ?

@stringhandler
Copy link
Copy Markdown
Author

I did add this issue to discuss it #341, mainly to catalogue my thoughts, but we can brainstorm it there maybe.

@apoelstra
Copy link
Copy Markdown
Collaborator

we may want to be sparing with version upgrades.

In the 8 years Liquid has been deployed, we have literally never used any of the multiple script upgrade mechanisms that exist, except when we deployed Taproot. If we find ourselves running low on version numbers there are lots of alternate schemes we could deploy, but I'm skeptical that we will.

Do you think we need a version for BlockstreamResearch/rust-simplicity#345 ?

No. That is just fixing rust-simplicity to support functionality that was already deployed.

@stringhandler
Copy link
Copy Markdown
Author

I've added stringhandler#1 as a possibly versioning solution. I'll give it some more thought though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants