Pulp Fiction and multiple OP_RETURN, valid tx on testnet

[BTCW]

How Jules ended up on the blockchain

Like many others, I've experimented with including arbitrary code in valid transactions.

The contemporary standard-method is OP_RETURN, with a huge disclaimer: only one per transaction - or the tx will be invalid (interestingly, coinbase transactions may and often do contain several OP_RETURN, but that's a different story).

The manual says you can push up to 80 bytes of data using this method, as it appears that many in the community are skeptical to the existence of OP_RETURN (the blockchain should contain tx data, not arbitrary junk, fine, I agree)

Anyway, I thought of one of my favorite movie quotes, from Pulp Fiction (1994) in which characters Jules reads quotes "Ezekiel 25:17" (Quentin Tarantino pushed his liberal arts beautifully here, no real bible contains these words) before killing his victims:
 

The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men. Blessed is he, who in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children. And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy my brothers. And you will know my name is the Lord when I lay my vengeance upon thee.


If we take this, then perform an ASCII to hex conversion, we get:

Code:

5468652070617468206f6620746865207269676874656f7573206d616e206973206265736574206f6e20616c6c2073696465732062792074686520696e6571756974696573206f66207468652073656c6669736820616e642074686520747972616e6e79206f66206576696c206d656e2e20426c65737365642069732068652c2077686f20696e20746865206e616d65206f66206368617269747920616e6420676f6f642077696c6c2c2073686570686572647320746865207765616b207468726f756768207468652076616c6c6579206f66206461726b6e6573732c20666f72206865206973207472756c79206869732062726f746865722773206b656570657220616e64207468652066696e646572206f66206c6f7374206368696c6472656e2e20416e6420492077696c6c20737472696b6520646f776e2075706f6e207468656520776974682067726561742076656e6765616e636520616e6420667572696f757320616e6765722074686f73652077686f20776f756c6420617474656d707420746f20706f69736f6e20616e642064657374726f79206d792062726f74686572732e20416e6420796f752077696c6c206b6e6f77206d79206e616d6520697320746865204c6f7264207768656e2049206c6179206d792076656e6765616e63652075706f6e20746865652e

Clearly more than 80 bytes. If fact, it is 495 bytes.

Hm. What next. I really wanted this one to stick on the blockchain. So I fired up Ecectrum (in testmode), and from the menu, I chose "pay to many". Using Notepad++, I ended up with the following recipients (in other words, I just sliced the sling into 40-byte strings, and added a "0" so nothing would actually be transferred to a provably unspendable address.)

Like this:



Since some of it is cropped in the image, here is the full list of "recipients":

Code:

OP_RETURN 5468652070617468206f6620746865207269676874656f7573206d616e206973206265736574206f,0
OP_RETURN 6e20616c6c2073696465732062792074686520696e6571756974696573206f66207468652073656c,0
OP_RETURN 6669736820616e642074686520747972616e6e79206f66206576696c206d656e2e20426c65737365,0
OP_RETURN 642069732068652c2077686f20696e20746865206e616d65206f66206368617269747920616e6420,0
OP_RETURN 676f6f642077696c6c2c2073686570686572647320746865207765616b207468726f756768207468,0
OP_RETURN 652076616c6c6579206f66206461726b6e6573732c20666f72206865206973207472756c79206869,0
OP_RETURN 732062726f746865722773206b656570657220616e64207468652066696e646572206f66206c6f73,0
OP_RETURN 74206368696c6472656e2e20416e6420492077696c6c20737472696b6520646f776e2075706f6e20,0
OP_RETURN 7468656520776974682067726561742076656e6765616e636520616e6420667572696f757320616e,0
OP_RETURN 6765722074686f73652077686f20776f756c6420617474656d707420746f20706f69736f6e20616e,0
OP_RETURN 642064657374726f79206d792062726f74686572732e20416e6420796f752077696c6c206b6e6f77,0
OP_RETURN 206d79206e616d6520697320746865204c6f7264207768656e2049206c6179206d792076656e6765,0
OP_RETURN 616e63652075706f6e20746865652e,0

Lo and behold, I could sign and broadcast the tx without a problem. It was included in a block within minutes. The net result is here:

https://blockstream.info/testnet/tx/68838b9f4fb8f23db46cf9e71511211a4d66b45fd02320481cfc5c352433dcb9?expand

Looks I have to work on the ordering, though, it seems the entires get lexicographically sorted so that the text turns up scrablmed. But still, yeah baby! Jules famous words are now forever imprinted on the blockchain.

Well.... that of the testnet. When trying to reproduce this on the mainnet, I got an error saying I was using too many OP_RETURN. Really?  

I was surprised the "one only" rule is disabled on the testnet.

Kinda cool, I thought. Maybe everybody already knew? Ye like?




If you have another trick for mainnet, I'm all ears! One that doesn't rely on OP_RETURN would be nice. Thanks!

[1713906041]

1713906041

[1713906041]

1713906041

[1713906041]

1713906041

[nc50lc]

If you have another trick for mainnet, I'm all ears! One that doesn't rely on OP_RETURN would be nice. Thanks!

You can make use of CPFP, and the miner's rules regarding transaction grouping,
to include multiple transactions each with a single OP_Return in a single block and stay in the correct order.

That will require your to create multiple transactions, one with slightly higher fee rate than the parent.
The parent should be the first line, then spend one of the unconfirmed output(s) to create the child txn for the second line, repeat.

Since (I presume) most Blockchain parsers parse whole block clusters or individual blocks,
the transactions need to be included in a single block to be displayed as whole.

Actually, I've tried this 4 months ago: https://bitcoinstrings.com/blk02089.txt, it's in my local tongue but you can easily tell the non-random lines.
TXs:

• https://blockstream.info/tx/6bcf6c8fcbccbf2d4cae6adeff9459898cd28f1a3c7be368d5470684d25ef06e?expand
• https://blockstream.info/tx/03d67297c453f5c1c0c0b4d7e47ccf6917e00ca449ff6e12d2a74f7fedb6280e?expand
• https://blockstream.info/tx/88223f836473222cb0e72f68f2b669be5fb03a4840f73553d17aa819af1f6ac8?expand

But please, do not spam in the blockchain  :P

[pooya87]

only one per transaction - or the tx will be invalid (interestingly, coinbase transactions may and often do contain several OP_RETURN, but that's a different story).

it's because there is a big difference between being "invalid" and "non-standard". 1 OP_RETURN per tx is a standard rule.

The manual says you can push up to 80 bytes of data using this method,

again the same difference. 80 is a standard rule.

Well.... that of the testnet. When trying to reproduce this on the mainnet, I got an error saying I was using too many OP_RETURN. Really? 

I was surprised the "one only" rule is disabled on the testnet.

majority of standard rules are disabled on testnet to allow testing these weird things.

on testnet try to include the entire thing inside one OP_Return and if that failed simply drop the OP_Return and push the data as a single byte array to the stack meaning 0x4def0154686520....6865652e.
Electrum may fail signing this though, but the last one is definitely possible.

If you have another trick for mainnet, I'm all ears! One that doesn't rely on OP_RETURN would be nice. Thanks!

put the long ass data inside one OP_RETURN in one output in one transaction and place that 1 tx in a new block and mine it yourself

[BTCW]

If you have another trick for mainnet, I'm all ears! One that doesn't rely on OP_RETURN would be nice. Thanks!

put the long ass data inside one OP_RETURN in one output in one transaction and place that 1 tx in a new block and mine it yourself

But of course.... the whole shebang in a single OP_RETURN. Worked like a charm (text looks better too - bottom right):

https://blockstream.info/testnet/tx/2e7510b147e7eaabc6dcee9103d1ac6bed1cbc4ba7bd3cb8e3818e73cb07f4b4?expand

That concludes it. Thanks!