Topic: Can Inscriptions Be Restricted Without a Hard Fork? (Read 148 times)

Not sure how you've arrived at that conclusion, but it doesn't sound correct.


From my understanding, the discussion on the mailing list and GitHub about removing the limits on OP_RETURN are to do with standardising data storage, not preventing it.

A few relevant quotes from Feb's Mailing list discussion:




None of that would prevent people from adding non-transactional data to the blockchain.  Quite the opposite, in fact.

It is really possible to restrict those ordinals or inscriptions without a hard fork. And the method in that matter can impose a limit on the size of the data of witness that can be included in a block. And this will be an effective way to prevent ordinal creation.

      Second, if it is to be hidden, the agreed targets must also be changed to invalidate the transaction. And this will only happen if the majority of the miners will agree to this changes.

*** We can Ban ordinals or Inscriptions ***

I'm sure it's possible (although many peeps here on Bitcointalk would claim the opposite). It's just the matter of core dev team starting to treat ordinals as a bug, as an exploit. Once they start treating it as a bug, they will find a way to stop this plague. This is what happened to the double-spend bug, unlimited Bitcoins bug and all other serious Bitcoin bugs (not many of them were exposed so far). No hard fork necessary.

The solution would involve some tinkering with OP_RETURN (be it a complete removal or size limits/metadata type filtering) and should be pretty straightforward.

This will not stop inscription which has very small size, such as BRC-20 and ORC-20 which use Ordinal standard. For example this JSON data to transfer BRC-20 ordi token[1] only has 56 character or 56 bytes. And counting additional OPCODES/metadata which is part of Ordinals standard[2], it's still less than 100 bytes.

---

[1] https://domo-2.gitbook.io/brc-20-experiment/#transfer-brc-20
[2] https://docs.ordinals.com/inscriptions.html

Yes, you can ban them. By simply banning ALL transactions.
Or all transactions with multiple outputs.

You cannot ban them without also banning regular standard transactions that they can be made to resemble, since they could embed their data in extra fake output addresses, either P2PK or P2PKH (sacrificing whatever amount is sent there).

So in practice, no, you cannot ban them, unless you go to the extreme of banning public addresses [1].

[1] https://bitcointalksearch.org/topic/m.61980991

Of course. One solution is mempool-level restriction, then it would be non-standard, and people would need to contact with mining pools, to get such transactions included. Another solution is consensus-level restriction. And because everything is about looking at a single transaction and deciding that "it breaks rule X", then it can always be done.

Technically, you can consider very restrictive soft-fork, that will allow adding only a single coinbase transaction, that will contain a commitment to a new UTXO tree. Is it soft-fork? Yes. Will it stop inscriptions? Yes. (as well as all other transactions, but well, it will be a perfectly valid soft-fork)

There are many different options. The main reason why you cannot see a soft-fork proposal here and now, is that a lot of methods will do more harm than good. For example, in Grin altcoin, it is much harder to insert any data to the chain. We could follow the same path, but then Bitcoin would be much more limited than it is today. Also one more thing: people could use standard timelocked transactions that are valid today, but could be included for example after block 1,000,000, and you don't want to make them non-standard, or invalidate them.

It will work, but it will invalidate more timelocked transactions than you want to invalidate. Also, people could switch for example to storing data as unspendable uncompressed P2PK, or use other "meaningful" data to store things, for example inside signatures: " OP_SWAP OP_CHECKSIGVERIFY OP_SWAP OP_CHECKSIGVERIFY ... OP_CHECKSIG".

Previously I have stated in another thread that it is possible to restrict the size of the data embedded in a Taproot script, which will cause a soft fork.

Also see this Bitcoin Stack Exchange question which also has some solutions: https://bitcoin.stackexchange.com/questions/118197/ddos-attack-via-brc-20-ordinals-on-bitcoin

A simple question really. Regardless of how people feel about Ordinals or Inscriptions, is it possible to ban them or otherwise restrict them without a hard fork? How would it work? I suppose a limit on the size of the witness data can be imposed after a designated block. Will that work?


I am not looking for opinions. Replies stating opinions on Ordinals or Inscriptions, and any replies to those opinions will be removed.