So how is it "file storage"? If it's just possible to embed a file (that you need a file carver to extract), why don't you characterize Knots the same way, given that it's trivial to embed a contiguous TIFF in standard Knots txs?

You've characterized OP_RETURN data carrier as "file storage" multiple times now. Is there any support in Bitcoin or Bitcoin Core for actually storing or viewing "files" here in your mind?

That's a very Lukian move. Anything you disagree with is just "obvious misinfo". You blocked me despite my verifiable and provable claims.

the apparently sanctioned methods of adding files to Bitcoin

Where is "adding files" (much less viewing them!) a feature of Bitcoin or Bitcoin Core?

Because I can "add files" just as easily by making a transaction include a valid and contiguous TIFF file even with Knots-policy-standard txs.

Sorry, I thought I was asking @gregtonoski . I’m new on this site.

Maybe you can answer, then:

BIP-110 claims it can reduce the amount of arbitrary data on chain, but even napkin math shows that it, at best, gives a 0.6% increase in cost/byte for a spammer. It also does not prevent embedding contiguous image files even in policy standard Knots txs. Given its technical ineffectiveness, the remaining goal of "sending a message" is mere virtue signaling, no better than planting a sign on your lawn saying "outdoor air pollution is not welcome here!" What remaining reasons are there for supporting this?

^{BIP-110 claims it can reduce the amount of arbitrary data on chain, but even napkin math shows that it, at best, gives a 0.6% increase in cost/byte for a spammer. It also does not prevent embedding contiguous image files even in policy standard Knots txs. Given its technical ineffectiveness, the remaining goal of "sending a message" is mere virtue signaling, no better than planting a sign on your lawn saying "outdoor air pollution is not welcome here!" What remaining reasons are there for supporting this?}