Witness script validation to reject arbitrary data

From what I understand, things like inscriptions can only be inserted between two specific flags - OP_FALSE and OP_IF. Having a validation check to reject witness scripts that have arbitrary data between these two flags could be used to reject inscriptions while still allowing all the benefits of taproot. This will prevent people from overloading the network with txns geared solely for ordinals and brc-20 tokens.

Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb. Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot? Thanks, Moth

Sent from Proton Mail for iOS

> Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb.

A reason to not ban storing arbitrary/non-functional data is that people will still want to store things, so will start (ab)using useful data to do so, which is worse -- see Stamps[1], which stores Inscription-like data in fake outputs that consume UTXO set storage (using the Counterparty spec IIRC).

The UTXO set getting 'too big' is a much bigger problem than the chain getting bigger at closer to 4MB/10mins than the 'expected' ~1MB/10mins is (some nuance/argument to be had here, though).

> Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot?

Kinda? But if we want Taproot to enable large useful scripts, it's probably hard/impossible to have an undefeatable definition of 'not useful' to then filter out. You could say "scripts must not have any unreachable code (dead code)" but then it'd be easy to come up with Inscriptions 2.0 where the code is reachable but never used, rinse and repeat in a game of whack-a-mole.

In my opinion, it'd be wise to not incentivize people to do something worse by attempting to censor what they're currently doing, given that it could be a fair bit worse!

[1]: https://github.com/mikeinspace/stamps/blob/main/BitcoinStamps.md

Angus

On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> From what I understand, things like inscriptions can only be inserted
> between two specific flags - OP_FALSE and OP_IF. Having a validation check
> to reject witness scripts that have arbitrary data between these two flags
> could be used to reject inscriptions while still allowing all the benefits
> of taproot. This will prevent people from overloading the network with txns
> geared solely for ordinals and brc-20 tokens.
>

Unfortunately, there are many other ways to “inscribe” other than that particular trick.

>
> Is there a reason such a validation check is a bad idea? We already have
> OP_RETURN to store arbitrary data that is limited to 80kb. Was it an
> oversight that arbitrary data can be inserted between OP_FALSE and OP_IF
> when the size limit for witness scripts was lifted as part of taproot?
>

There have been some of us that had hoped for a slightly larger OP_RETURN such that we can store a tagged root of a hash-tree (~128-512 bytes). For instance, open time-stamps, ION, and my own privacy-focused Gordian Envelope (https://www.blockchaincommons.com/introduction/Envelope-Intro/), all consolidate large sets of proofs into a hash, which we use for L2 proofs-of-inclusion. My own preference is that the size can be large enough so you can store the hash, optionally have a signature on it, and have a few bytes for self-describing data (we like CBOR as it is quite small).

All of us held off for years asking for larger OP_RETURN or standardizing on a pay-to-contract BIP for the techniques we do use because of objections to putting anything on-chain. But now we are dismayed by the inscription technique that freeloads on the network mempool, the validation network, and volunteer unpruned full nodes.

For instance, I host an alternative explora instance (the source code base used by blockstream.info), offering it publicly via Tor so that there is more than a single server offering its details. Inscriptions combined with DOS attacks on Tor is making it more expensive for me to host and maintain this free privacy service.

There was a recent thread discussing raising the limit on OP_RETURN https://github.com/bitcoin/bitcoin/issues/27043

Here is an old relevant thread from open time-stamps: https://github.com/opentimestamps/python-opentimestamps/pull/14

I’m not sure what the solution is. I feel like I’ve been a good neighbor for some time on this topic, always recommending minimal on-chain data, and now I feel frustrated with this free-rider problem.

— Christopher Allen

On Mon, May 08, 2023 at 08:16:41PM +0000, Moth via bitcoin-dev wrote:

> From what I understand, things like inscriptions can only be inserted between two specific flags - OP_FALSE and OP_IF.

That's just an artifical limitation of the current inscription protocol. There are endless ways to embed arbitrary data in Bitcoin transactions. Blocking them all is a hopeless task.

> Having a validation check to reject witness scripts that have arbitrary data between these two flags could be used to reject inscriptions while still allowing all the benefits of taproot. This will prevent people from overloading the network with txns geared solely for ordinals and brc-20 tokens.
>
> Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb. Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot?

It's pointless to even try.

The current flood of inscription txs are very small, about 150vB, and embed very little data in the chain. They could have just as easily used OP_RETURN outputs or any number of other data encoding techniques. Blocking that kind of use-case is hopeless.

The _purpose_ of the current flood of BRC-20 inscriptions - tl;dr the creation of a new set of assets via an auction - is something that doesn't even require any data to be embedded in the chain at all. They could have implemented them with perfectly normal transactions indistinguishable from any other transaction. Blocking that is truly hopeless.

> They could have just as easily used OP_RETURN

outputs or any number of other data encoding techniques.

But doesn't OP_RETURN render the UTXO unspendable, thereby making it impossible to "trade" the minted BTC-20 tokens?

Moth

Sent from Proton Mail for iOS

On Mon, May 8, 2023 at 7:55 PM, Peter Todd <[pete@petertodd•org](mailto:On Mon, May 8, 2023 at 7:55 PM, Peter Todd <<a href=)> wrote:

> On Mon, May 08, 2023 at 08:16:41PM +0000, Moth via bitcoin-dev wrote:
>> From what I understand, things like inscriptions can only be inserted between two specific flags - OP_FALSE and OP_IF.
>
> That's just an artifical limitation of the current inscription protocol. There
> are endless ways to embed arbitrary data in Bitcoin transactions. Blocking them
> all is a hopeless task.
>
>> Having a validation check to reject witness scripts that have arbitrary data between these two flags could be used to reject inscriptions while still allowing all the benefits of taproot. This will prevent people from overloading the network with txns geared solely for ordinals and brc-20 tokens.
>>
>> Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb. Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot?
>
> It's pointless to even try.
>
> The current flood of inscription txs are very small, about 150vB, and embed
> very little data in the chain. They could have just as easily used OP_RETURN
> outputs or any number of other data encoding techniques. Blocking that kind of
> use-case is hopeless.
>
> The _purpose_ of the current flood of BRC-20 inscriptions - tl;dr the creation
> of a new set of assets via an auction - is something that doesn't even require
> any data to be embedded in the chain at all. They could have implemented them
> with perfectly normal transactions indistinguishable from any other
> transaction. Blocking that is truly hopeless.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

Le 08/05/2023 à 23:43, Christopher Allen via bitcoin-dev a écrit :

> There was a recent thread discussing raising the limit on
> OP_RETURN https://github.com/bitcoin/bitcoin/issues/27043

Indeed we already discussed all of this, and the conclusion was: there are no reasons to impose limits, because people will find some deviant (or not) workarounds (like Stamps), and fees will regulate this

And how to control the value of what is stored? If I store e=mc2, the way I like since as many said it's super easy to find plenty of ways to store in bitcoin, this one is short and supposed to have more value than bitcoin, no?

Personnally I think of course that you should store a reference to something and not the something, so a few hashes and/or signatures which you cannot do with OP_RETURN today (80B Moth, not 80kB)

I don't see very well what can be done against the freeriders, except avoiding that they impact the whole network (a bit à la bittorrent), maybe the issue is more about decentralization rather than trying to impose limitations, so the decentralized miners can't have the whole image of the whole txs and hold low fees txs, which is not the case at all today, but it seems a bit utopic right now

Or maybe when the ordinal meme stuff/BRC20 will be proven to have finally zero value the market will self regulate