Vanilla inscriptions

[jotapea]

Hello! Impressive work done here.

I'm interested in the inscription functionality by itself, decoupled from ordinals.

1. Is it possible? If it is, its identifier would just be a txid?
2. Do you know about a project that already does this? If not, will this functionality be something this project will work on? Or should I fork this repo and try (would need to learn rust/taproot) to make it work?

I'm interested in this because I'm looking for a simple and efficient way to write arbitrary data in Bitcoin just like ordinal inscriptions do, but without all the overhead of these being tied to ordinals. I'm thinking that it should not need any additional databases or complicated stack, it would just need the functionality of checking if there are inscriptions in a transaction by txid.

[casey]

Hello! Impressive work done here.

Thank you!

I'm interested in the inscription functionality by itself, decoupled from ordinals.

I think this is interesting too, and I'd like to support this. To be clear, is what you're interested in the ability to publish data, in a transaction, and then have it be viewable on web page, like ordinals.com, but without worrying about it being publicly transferrable?

If so, I think we can definitely support this easily with ord.

1. Is it possible? If it is, its identifier would just be a txid?

The identifier would still be the inscription ID, which is TXIDiN, where N is the index of the inscription in the transaction. This is because we might have multiple inscriptions per transaction. This is useful even if you don't intend to transfer the inscriptions, for example if you want to publish multiple files in one transaction.

2. Do you know about a project that already does this? If not, will this functionality be something this project will work on? Or should I fork this repo and try (would need to learn rust/taproot) to make it work?

As far as I know, there are no other tools to make inscriptions. This would be very easy to ord to support, and without needing to build an index, all you'd need is a Bitcoin Core node, but it could be pruned.

I'm interested in this because I'm looking for a simple and efficient way to write arbitrary data in Bitcoin just like ordinal inscriptions do, but without all the overhead of these being tied to ordinals. I'm thinking that it should not need any additional databases or complicated stack, it would just need the functionality of checking if there are inscriptions in a transaction by txid.

I think a great first step would be an ord wallet publish command, which would create an inscription without caring about where it goes. We can get into the details of what "without caring about where it goes" actually means when we start working on it.

[jotapea]

Great! And I like calling the feature publish, it makes sense.

To be clear, is what you're interested in the ability to publish data, in a transaction, and then have it be viewable on web page, like ordinals.com, but without worrying about it being publicly transferrable?

I'm thinking these don't need functionality related to transferring them, they will just be "publications" of data. These would be the equivalent to Counterparty broadcasts, which are separate from their (transferrable) assets.

About these being viewable on a web page, what I imagine is these would be part of shared standards between ordinal vs vanilla inscriptions. But about having specifically ordinals.com show them I'm not sure, maybe it can make sense depending on how it is presented.

[casey]

I'm thinking these don't need functionality related to transferring them, they will just be "publications" of data. These would be the equivalent to Counterparty broadcasts, which are separate from their (transferrable) assets.

It's actually easier to make them transferrable, then they're just inscriptions. Making them not transferrable would be more work. We'd need to:

• Add a flag to an inscription to note that it was not assigned to any staoshi in the outputs
• Burn the output by sending it to an op-return

[jotapea]

The main benefit I see for vanilla inscriptions / publications is their deployment simplicity, no need to setup the ordinal sat-tracking stack.

I can understand the work needed to decouple the inscriptions from ordinals in the current state of the project. But, I believe this flexible inscriptions approach will support the Bitcoin ecosystem more broadly, and make this project one to follow for general data storage standards in the timechain.

[tyjvazum]

I'm thinking these don't need functionality related to transferring them, they will just be "publications" of data. These would be the equivalent to Counterparty broadcasts, which are separate from their (transferrable) assets.

It's actually easier to make them transferrable, then they're just inscriptions. Making them not transferrable would be more work. We'd need to:

* Add a flag to an inscription to note that it was not assigned to any staoshi in the outputs

* Burn the output by sending it to an op-return

Wouldn't doing it with them being transferable already be supported, by simply using, for example, a JSON file containing whatever arbitrary data?

I've been imagining some potential protocols that could be built on top of your work (including some that could extend the functionality of ord), that would need the feature this issue is discussing. Transferability doesn't make sense for these use cases, so it'd need to be dealt with either in ord or in the higher-level protocol. I think it'd be better for ord to support this general use case, rather than each higher-level protocol needing to detect and ignore transfers, but of course I'd understand if it's just too complicated to implement in ord.

If adding support to ord seems logical to you, I'd love to help out with the code changes. I'm an experienced programmer in several languages, but only recently started learning Rust. However, I think I could be of help with some guidance.

[tyjvazum]

As I continue to think about it, isn't this feature really just about exposing a method to create arbitrary envelopes with a different string for the first OP_PUSH? Perhaps with another feature added to ord server so that it can take in a config file with the "magic strings" (really each a protocol specifier, like "ord" from the link below) that it should be parsing? That'd seem to make ord general-purpose enough to enable some of the feature extensions I'm imagining, which would be developed as additional software that uses ord internally.

I would think this should allow implementing the feature without making changes to how ord functions regarding its normal use case.

https://docs.ordinals.com/inscriptions.html?highlight=envelopes

[jotapea]

To start it can be simple like:

ord wallet publish FILE

Which could just write the file without a 'protocol specifier' by being empty, 0, null, or whatever is best.

[tyjvazum]

To start it can be simple like:

ord wallet publish FILE

Which could just write the file without a 'protocol specifier' by being empty, 0, null, or whatever is best.

I think I better understand what you're looking for now. You seem to want a minimal program that has only two methods, publish and let's call the other inspect for now, which would take a TXID as input and return any inscriptions, if there are any. That seems like it might be a difficult change since ord is currently a single binary, but I think it'd require my proposal for arbitrary envelopes as a basis.

@casey, I look forward to hearing your thoughts on the recent messages. I'd love to help implement arbitrary envelopes, and perhaps the code modularization work that @jotapea is describing, assuming of course you think they're worthwhile directions to go in.

[jotapea]

From the inscriptions doc:

The inscription content model is that of the web. An inscription consists of a content type, also known as a MIME type, and the content itself, which is a byte string.

This fully describes the content model for inscriptions, with clear human readability as "version 0". This is simple, thus powerful. And relevant, currently being discussed.

Then, I'm thinking that for a "vanilla inscription" / envelope function, something like replacing ord for 0 as this "potocol specifier" can make sense. Envelopes formatted like "version 0" ordinal inscriptions.

ord wallet envelope FILE

No real need for a new concept like publish, as the feature commands are quite self explanatory. But publish does sound cooler ;) and better encapsulates the idea of "writing in Bitcoin".

[tyjvazum]

@jotapea, can you confirm if what you want is something like "a minimal program that has only two methods, publish and let's call the other inspect for now, which would take a TXID as input and return any inscriptions, if there are any" and doesn't have any of the other code from ord?

[casey]

This is my proposal:

1. Add a command to ord that doesn't require the index to be synced and which can make an inscription on a UTXO in the wallet. Since the index isn't synced, this will require careful UX to avoid sending an important UTXO. The inscription will be the same as a normal inscription.
2. Add a command to ord that doesn't require the index to be synced to get the content of an inscription, by inscription ID.
3. Other features, like #1333 can later be leveraged to make the inscription immobile, if it is the authors intent to signal that transferring the inscription is not meaningful, and it is not intended to be sent.

If there's more functionality to be added, please articulate what, exactly, that functionality is, and why we can't use the features above as a base to add it.

All the desiderata here (and apologies if I missed anything 😅) seems to be implementable with these minimal features above, which does not require an additional envelope protocol, or any large changes to ord. Additionally, this allows users who want to view this content so simply link to the inscription on ordinals.com.

[jotapea]

@jotapea, can you confirm if what you want is something like "a minimal program that has only two methods, publish and let's call the other inspect for now, which would take a TXID as input and return any inscriptions, if there are any" and doesn't have any of the other code from ord?

@tyjvazum, yes I agree with this minimal implementation (and I'm currently learning rust to be able to help!).

@casey, the changes proposed should work, but I still find them too coupled to ordinals. This burning you describe can still be done as ordinal's specific use cases though.

Maybe the best move forward for a feature like this is to build it separate, at least until ord can integrate it as described while avoiding confusion with the burn alternative.

[casey]

@casey, the changes proposed should work, but I still find them too coupled to ordinals. This burning you describe can still be done as ordinal's specific use cases though.

Can you be specific about what the problem is? "too coupled to ordinals" is very general.

You can definitely build it in a separate repo, and different protocols using ordinals and envelopes are encouraged! But I do think publishing things is useful functionality, and would like ord to support it. If we can land something simple and easy that can be improved later, this could all be done with inscriptions.

[jotapea]

I believe that the need to burn (and the disclaimer) already shows tight coupling. Maybe a separate non-ordinals-aware wallet is more appropriate for publishing...

[casey]

I believe that the need to burn (and the disclaimer) already shows tight coupling. Maybe a separate non-ordinals-aware wallet is more appropriate for publishing...

Maybe so! Let me know if you put something up. I'd like to keep this issue open for ore. Let's use it to explore easier publishing functionality. The existing conversation provides a lot of great context on my thinking around this.

[jotapea]

@casey @tyjvazum https://github.com/jotapea/pub/commits/pub-v2

Consider this a MVP that has not been tested with real transactions yet. Most of the work was commenting out db functionality, with very minimal adjustments to make it "work" (only tested with dry-run).

With the potential to make this alternative repo even smaller by removing more sat-tracking specific features, I believe it can make sense to continue it as a separate (but related) project... what do you think? And what should I work on before trying a real transaction with it?

[casey]

I honestly just haven't been convinced there is a real need not to just improve inscriptions here. So this should be turned into issues with specific asks (burn on inscribe, mark as non transferrable on inscribe, etc). Other dev work can continue elsewhere 🙏

[casey]

Leaving open, since a lot of those specific asks were covered in this issue's comments, and don't want to lose them.

[tyjvazum]

@casey @tyjvazum https://github.com/jotapea/pub/commits/pub-v2

Consider this a MVP that has not been tested with real transactions yet. Most of the work was commenting out db functionality, with very minimal adjustments to make it "work" (only tested with dry-run).

With the potential to make this alternative repo even smaller by removing more sat-tracking specific features, I believe it can make sense to continue it as a separate (but related) project... what do you think? And what should I work on before trying a real transaction with it?

@jotapea, can you enable issues and/or discussions? I'd like to provide some feedback. This isn't the place to do it though.

[jotapea]

@tyjvazum issues have been enabled.

@casey it does not have to be a separate project, I can see this basic publishing included as a feature of ord. But I am interested in making a no-index version work. So my next question is if I just "ignore" the index but proceed making inscriptions (like what I am trying to achieve in the repo fork), will these still be "compliant" ordinal inscriptions? If that is the case, then there is no real need to change the protocol_id.

How do you foresee people making adjustments to the software, like when should the protocol_id be kept vs being a different one?

[stet]

Great discussion! I came here looking to see if any of this was already being talked about. Recently tweeted this: https://twitter.com/sull/status/1626824019176456193

As an independent thought experiment before finding this thread, I might as well chime in.

Related to the specifics of this thread, I think there is merit in having a no-index ref client (vanilla publisher wallet). I also agree with @casey that Ord should have a minimal publish mode to handle content that lets just say isnt intended to be a part of a market and so those related features should be able to be...skipped and/or extend the protocol to make clear there is support for general publish (vanilla inscriptions) use case.

Another line oif thought that was even touched on in this thread is the potocol specifier (prefix). Software depends on this, AFAIK, for targeted data parsing. I suppose additional verification is done too by analyzing the envelope content. But the idea of Ord forking is going to happen so this discussion is important now.

What are your thoughts on implementing namespaces to distinguish among many Ord runner instances where a subset of conventions, rules, instructions etc can be applied with a namespace metadata file inscribed to a parent ordinal/sat owned by the namespace creator? This requires thinking broadly and into the future, as well as accepting the likely occurrences with or without forward thinking proposals.

So a namespace can be added to the protocol specifier like protocol:namespace

E.g . ord:stet

This actually introduces a loose SLD name system, if we continue to take pretend things and make them real through a concerted community and dev effort.... consensus.

I'm sure at this point you are thinking... is ORD now a TLD in this Ordinal world? Sure why not?

E.g. stet.ord is the pointer to the Ordinal tree associated with it. It could be a complete website directory of onchain inscriptions (that would be cached by apps).

In Ordinal world, we rely on software to turn pretend things into reality. It is arbitrary from the top and therefor all the way down, if we choose to. Suddenly. this simple idea could result in organized onchain data repos with its own description and metadata, used in different ways and interfaces and easily acced with a ad hoc DNS system where .ORD is the TLD.

Bitcoin/Ordinal Wallets will become "web browser" hybrids where all content is onchain and cached for speed.

This may discouage some rogue forking (not that there's anything nec wrong with that) and encourage creating namespaces and keeping Ordinal as the umbrella project. One anticipated reason to fork with new protocol specifier would be to duplicate rare sat serials in an attempt to recreate demand for speculative scarcity. By supporting namespaces, I think it would make such shitords motivation more obvious.

I'll end with an example of a namespace.

nytimes.ord

In the namespace metadata file, it states it is a text-only archive of articles. There is an index page (versioning?) that just lists and links to all articles or just an intro/summary statement with link to centralized dynamic page that lists all onchain articles (inscription IDs). This namespace could also instruct apps to use certain flags to disable tracking, not bind to sats or generally opting out to being a tradable "NFT". Just inscriptions.

You get the idea ;)

I'm looking forward to your feedback.

[jotapea]

Solution found? https://github.com/supertestnet/breaker-of-jpegs

Joking... but is kinda funny that an inscription can't get more "vanilla" than this ;P

[casey]

The way to support this would be to reserve an even tag as being forever unsupported, which would lead to inscriptions made with that tag to be perma-unbound.