Content-Type Alias field

[conduition]

This idea originated here: https://github.com/ordinals/ord/discussions/2879#discussioncomment-7892461

The basic premise is to replace the content-type data-push in every inscription with predefined sequences of (or just lone) magic byte aliases. There is no need for every text inscription to include the redundant text text/plain;charset=UTF-8 in the witness inscription. Instead the inscription could just include a single magic byte, e.g. 0x74 (the character t in ASCII). This is a huge efficiency gain for small inscriptions like BRC20.

I ran some calculations here, and estimated that on average, this simple trick could save about 35,932 bytes of witness space per block on average. At a fee rate of 100 sat/vbyte, that's about 890,000 sats (currently \~$400 USD) per block, every 10 minutes, which could be saved.

@casey suggested to define a new inscription field type, which for now I'll call the 'content type alias' field. We'd define a canonical mapping from aliases to web content type strings. ord and other inscription indexers would need to be updated to recognize this header, but due to the efficiency savings for BRC20, it seems like a no-brainer to me that inscribing software would adopt it.

[lifofifoX]

Not convinced the savings in bytes is worth relying on an offchain content type mapping.

Perhaps, a better approach might to be explore setting certain tags that apply to all inscriptions within a batch. At the moment, content type, parent and delegation tags are repeated for every inscription when you batch inscribe. If there's a way to set them just once for all inscriptions within a batch, it'll result in a significant saving without having to rely on any offchain mapping.

Ref #2930

[casey]

Another big issue is whether or not BRC-20 inscription software will adopt it. If they're using ord, they'll automatically adopt it when they upgrade, but if they aren't or don't upgrade, it will be hard to get them to change their software, and this might see limited adoption.

[casey]

Not convinced the savings in bytes is worth relying on an offchain content type mapping.

Perhaps, a better approach might to be explore setting certain tags that apply to all inscriptions within a batch. At the moment, content type, parent and delegation tags are repeated for every inscription when you batch inscribe. If there's a way to set them just once for all inscriptions within a batch, it'll result in a significant saving without having to rely on any offchain mapping.

Ref #2930

I like this idea, but I don't think we can do it for subtle reasons. If tags apply to all inscriptions in a batch, then ord has to store a copy of the tag in the database for each inscription, it's essentially a DoS vector: user makes a batch of 1000 inscriptions, each has a 1kb tag, we must store 1mb in the database. This is a write amplification. Also, it breaks the model of each inscription being self-contained, which would make the code more complicated.

[conduition]

Not convinced the savings in bytes is worth relying on an offchain content type mapping.

Maybe we are thinking on very different scales, but i think 36 kilobytes of witness space per block is absolutely worth it. That's $21 million USD of fees per year (at current prices). Even if only 10% of inscriptions use the content-type alias, Isn't that worth such a small change?

[conduition]

Another big issue is whether or not BRC-20 inscription software will adopt it. If they're using ord, they'll automatically adopt it when they upgrade, but if they aren't or don't upgrade, it will be hard to get them to change their software, and this might see limited adoption.

I think BRC20 devs recently said they were going to freeze their ord version at 0.9. That would suck because they wouldn't get any fee savings from any improvements in ord, nor would they recognize inscriptions made using newer versions of ord.

[sull]

Not convinced the savings in bytes is worth relying on an offchain content type mapping.

Maybe we are thinking on very different scales, but i think 36 kilobytes of witness space per block is absolutely worth it. That's $21 million USD of fees per year (at current prices). Even if only 10% of inscriptions use the content-type alias, Isn't that worth such a small change?

in favor of this.