Witness script validation to reject arbitrary data

Witness script validation to reject arbitrary data
2023-05-08 21:33 ` angus
                   ` (2 more replies)
  
From: Moth @ 2023-05-08 20:16 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1988 bytes --]

 permalink raw reply	[|nested]
2023-05-08 21:33 ` 
                   ` 
  
From: Moth @ 2023-05-08 20:16 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1988 bytes --]

 permalink raw reply	[|nested]
2023-05-08 20:16 [bitcoin-dev] Witness script validation to reject arbitrary data Moth
  2023-05-08 21:33 ` angus

  2023-05-09 17:45   ` Aymeric Vitte
  2023-05-08 23:55 ` Peter Todd
  
From: Christopher Allen @ 2023-05-08 21:43 UTC (permalink / raw)
  To: Moth, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5407 bytes --]

 permalink raw reply	[|nested]
2023-05-08 20:16 [bitcoin-dev] Witness script validation to reject arbitrary data Moth
  2023-05-08 21:33 ` angus
  2023-05-08 21:43 ` Christopher Allen

  2023-05-09 12:20   ` Moth
  
From: Peter Todd @ 2023-05-08 23:55 UTC (permalink / raw)
  To: Moth, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2023-05-08 23:55 ` Peter Todd

  
From: Moth @ 2023-05-09 12:20 UTC ( / )
  To: pete, bitcoin-dev



> 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
2023-05-08 21:43 ` Christopher Allen

  
From: Aymeric Vitte @ 2023-05-09 17:45 UTC (permalink / raw)
  To: Christopher Allen, Bitcoin Protocol Discussion, Moth

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]



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


[-- Attachment #2: Type: text/html, Size: 2208 bytes --]

 permalink raw reply	[|nested]