Inscriptions are designed to mimic an HTTP request. Each has some headers, and a body composed of chunked bytes.
Most inscriptions contain a Content-Type header, again like HTTP requests.
For some reason, the creator of inscriptions chose to include the content type as a full MIME type string inside the inscription data, which ends up getting written to the blockchain witness data.
This is criminally inefficient when obvious alternatives abound, like using succinct prearranged byte sequences to imply certain common mime types.
As a result, each the last 100 blocks (822333 - 822433) contain, on average, 36000 bytes of redundant HTTP header data, the majority of which is just the string "text/plain;charset=utf-8" repeated ad nauseam among thousands of BRC20 minting transactions.
36000 witness bytes is comparable to around 45 normal payment transactions. Not 45 signatures - 45 entire transactions.
If the inscribers paid a fee rate of 100 sat/vB, those 36000 witness bytes are worth about 900,000 sats (about $400 USD).
And this is happening every block. 10 minutes passed? 900k more sats spent on uploading "text/plain;charset=utf-8" to the blockchain a few hundred more times.
All this money paid to miners just to place redundant headers in the blockchain. Don't even get me started on how BRC20 encodes the body of their inscriptions...
I am afraid that the people trading this crap do not care about fees, i.e. fees are still too low for them.
reply
This is indeed surprising. Bitcoin transaction opcodes are magic numbers, because that's the nature of all byte code interpreters. Encoding MIME type using a magic number would be perfectly in-line with how Bitcoin transactions are built.
Well, at least they aren't using XML to encode data inside inscriptions. (I sort of wish this were true, because that would be very funny.)
reply
sounds like the concept had been really thought to the end... not.
reply