From: Moth <moth_oshi@proton•me>
To: pete@petertodd•org, bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Witness script validation to reject arbitrary data
Date: Tue, 09 May 2023 12:20:20 +0000 [thread overview]
Message-ID: <DIdMbqUq9IWkMf6OF2vrgMBaQ-8-ZJteqOcp6TM-7h6f2D2a_PG8GFxFHjdB8Ftsd6R0NFM2A6FmboJfiT97RbWdeG6yIaIImM12-BAKkX4=@proton.me> (raw)
In-Reply-To: <ZFmMDYKxd7Uw6A4R@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
> 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
[-- Attachment #2: Type: text/html, Size: 3629 bytes --]
prev parent reply other threads:[~2023-05-09 12:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 20:16 Moth
2023-05-08 21:33 ` angus
2023-05-08 21:43 ` Christopher Allen
2023-05-09 17:45 ` Aymeric Vitte
2023-05-08 23:55 ` Peter Todd
2023-05-09 12:20 ` Moth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='DIdMbqUq9IWkMf6OF2vrgMBaQ-8-ZJteqOcp6TM-7h6f2D2a_PG8GFxFHjdB8Ftsd6R0NFM2A6FmboJfiT97RbWdeG6yIaIImM12-BAKkX4=@proton.me' \
--to=moth_oshi@proton$(echo .)me \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox