Can Inscriptions Be Restricted Without a Hard Fork?

[odolvlobo]

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.

[NotATether]

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?

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

[vjudeu]

is it possible to ban them or otherwise restrict them without a hard fork?

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)

How would it work?

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.

I suppose a limit on the size of the witness data can be imposed after a designated block. Will that work?

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: "<signature> OP_SWAP OP_CHECKSIGVERIFY <signature> OP_SWAP OP_CHECKSIGVERIFY ... <pubkey> OP_CHECKSIG".

[tromp]

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?

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://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991

[ABCbits]

I suppose a limit on the size of the witness data can be imposed after a designated block. Will that work?

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.

Code:

{"p":"brc-20","op":"transfer","tick":"ordi","amt":"100"}

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

[serveria.com]

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.

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.

[bettercrypto]

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 ***

[DooMAD]

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.

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

Ordinals Inscriptions don't use OP_RETURN, they are embedded within the script of a taproot input.

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:

Peter Todd pete at petertodd.org
Sun Feb 5 12:06:33 UTC 2023

On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte <aymeric at peersm.com> wrote:
>I think logically:
>
>- if you want to store something big and can afford several txs in your
>design, then you use something like witness
>
>- if you want to store small things like signatures, addresses hashes
>and some metadata and your design does not make several txs easy, then
>you use OP_RETURN
>
>Then how can we move forward with several OP_RETURN and no size limit?

Because what matters is the impact on other users. OpReturn isn't in UTXO space and doesn't even take advantage of the witness discount, so it clearly has minimal impact.

Since it has minimal impact, there's no reason to micromanage exactly how people use it. Let them decide for themselves with the fee market. This is exactly the same as how we didn't put artificial limits on Taproot.

Andrew Poelstra apoelstra at wpsoftware.net
Sun Feb 5 18:06:18 UTC 2023


On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev wrote:
> Since bytes in the witness are cheaper than bytes in the script pubkey,
> there is a crossover point in data size where it will simply be cheaper to
> use witness data.  Where that crossover point is depends on the finer
> details of the overhead of the two methods, but you could make some
> reasonable assumptions.  Such a calculation could form the basis of a
> reasonable OP_RETURN proposal.  I don't know if it would be persuasive, but
> it would at least be coherent.
>

I agree with Peter that, given that users have found ways to store arbitrary
amounts of data on-chain if they really want, we might as well just make
OP_RETURN a free-for-all.

--
Andrew Poelstra

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