Status: idearough draftdraftproposalfinal reviewstable

Epoxy - Push all the data

Let's get a common way of placing data within the executed part of the script to ensure larger data size with default mining settings.

This document describes a protocol named "Epoxy" that will let what is currently known as OP_RETURN data be part of the executed script to a) ensure larger amounts of data to be added into one transaction with default mining configuration and b) let people have a way of using the data as part of the output puzzle for the transaction. Please share inputs and comments.

Background

Current statue of OP_RETURN

WIP:

The problem

Epoxy protocol definition

Epoxy should be considered a wrapper of current data - so it's about how data is stored and not what data is stored. We suggest wrapped protocols are named with an 𝑒 at the end like 'BCAT𝑒' 'B𝑒' and 'D://𝑒'

At this stage, there are two suggestions to solve this awaiting feedback from the community.

Suggestion A

All of the script is valid.

The first 3 instructions must be OP_NOP OP_TRUE OP_NOTIF

This sequence has been selected based on it being highly unlikely to be used because it does not make sense to sure regarding calculations, meaning the.

OP_NOP OP_TRUE OP_NOTIF
[pushdata size element1]
[pushdata size element2]
[pushdata size element3]
OP_ELSE
[Optional script]
OP_ENDIF

The optional script needs to be valid for the transaction to be accepted.

This indicates that the relevant data is placed in the n*3 location until n*3+1 = OP_ELSE

A challenge with this notation is that data can be placed in different ways (smaller than 75 can be added with just a single instruction) so it's suggested to always use OP_PUSHDATA1, OP_PUSHDATA2 or OP_PUSHDATA4

Suggestions B

Parts of the script is invalid. It will be the smallest change for the ecosystem but at the moment it's unclear what is the effects of having invalid code as part of the script.

The first 3 instructions must be OP_TRUE OP_NOTIF OP_RETURN

OP_TRUE OP_NOTIF OP_RETURN
[data just like opreturn today]
OP_ELSE
[whatever script]
OP_ENDIF

This indicates that the relevant data is placed in the n+3 location until n+3+1 = OP_ELSE


Great inspiration: https://blog.bsv.sh/the-prunability-and-non-permanency-of-your-data-the-case-of-op_return/


Please share inputs and comments.