Data Storage/Inscriptions

[Psifour]

The goal in making these a paired set of OIPs is that we can define a minimal/permissive standard for data storage [..., OP_0, OP_IF, 0x03, "ABC", ..., OP_ENDIF, ...] while also carefully documenting the current rules about what ord considers to be a valid inscription.

This will form the basis needed for future third-party/application-specific development that utilizes this technique while avoiding undermining ord's place as the 'reference implementation'.

The current targeted design is that OIP 0004 will define a data storage transaction very loosely. Specifically, any input that includes as part of it's witnessData[1:] the following structure:

• Any number of bytes to include signatures/etc, followed by OP_1, OP_IF
• A pushed string (eg. "ord", "brc") representing which protocol/sub-protocol this data is attributed to
• Any number of bytes, tags, or other content, followed by OP_ENDIF
• While not encouraged, inclusion of additional data after closing the envelope will not result in invalidation

This sets a strong baseline condition that is easy to check for and should encompass all current use cases of this envelope type.

OIP 0005 will then seek to strictly define the structure of Inscriptions and other data storage attempts that utilize the 'ord' to enable full backwards compatibility from this superset of the standard to the current restricted envelope that is utilized by the ord client.

By separating these two we gain multiple technical benefits, but more importantly it establishes the baseline for future application-specific envelope development.

[tyjvazum]

@Psifour, great initiative on setting this up. I think the issue of "carefully documenting the current rules about what ord considers to be a valid inscription" is top priority in Ordinals at the moment, with the ongoing discussion in https://github.com/tyjvazum/arb/issues/16, https://github.com/ordinals/ord/issues/2045, https://github.com/ordinals/ord/pull/2109, and https://github.com/ordinals/ord/discussions/2113.

[Psifour]

I very much agree, but I also expand that beyond ord inscriptions as I actually feel that may not be the absolute strongest use case (as you seem to agree with arb if I am reading your docs right).

We both seem to have come to similar ideas that the documentation should be a super-set of the possible designs/implementation and then restricted at an application-specific level. Very excited to have your eyes on this and hope we can arrive at documentation that will support and encourage development on top of the really effective set of rules that Casey pioneered.

[tyjvazum]

Yes, I think we seem to be very much in agreement.

I've implemented the concept of an Envelope Expansion, where inscription content and associated data is placed inside of a JSON wrapper that allows for backward-compatible upgrades. This was decided to avoid potential conflicts with the tag mechanism, to make integration with external tooling easier, and to enable automatic support in explorers, if only minimally, by displaying the JSON. It supports versioned subprotocols, specified in the JSON, and arb supports two top-level envelope protocols, ord and pub, which lacks sat tracking to enable use cases that don't require NFT functionality, of which I think there are many.

I see sat tracking as being the meaningful difference at the top-level (ord/pub) and I consider protocols like BRC-20, for example, to be a subprotocol of the ord protocol since it makes use of the sat tracking feature.

I'm quite interested in your thoughts on everything and look forward to participating in your documentation effort 👍

[tyjvazum]

@HGraphPunks is interested in an OIP process too and started a discussion at https://github.com/ordinals/ord/discussions/2156. Perhaps we can plan some next steps here so everyone can work together in a coordinated way. There seems to be significant attention to the need for standardization in the space right now.