From: angus <angus@toaster•cc>
To: Moth <moth_oshi@proton•me>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Witness script validation to reject arbitrary data
Date: Mon, 08 May 2023 21:33:24 +0000 [thread overview]
Message-ID: <Ny5lrlyxNcdDUKpy8_vYd8RRl5Q6brWkPDkaxRzjCgM7JF8HXRIZnfs1ubvmIA_OhwYwmdthSXyGsJ8CP8qQ0x0i82qbzlehNzuVtefSeHc=@toaster.cc> (raw)
In-Reply-To: <SzOndBJmU5RPVdT2IhiWUmw925vgy-KCwrbWC4_e8tHVj5VWUn-Tr50TjxTczUUDcaVjUJEiuLVmFjfmtZwwvLyuUSkrGVg9uNje2oARArc=@proton.me>
[-- Attachment #1.1.1: Type: text/plain, Size: 1435 bytes --]
> 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
[-- Attachment #1.1.2.1: Type: text/html, Size: 5931 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
next prev parent reply other threads:[~2023-05-08 21:42 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 [this message]
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
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='Ny5lrlyxNcdDUKpy8_vYd8RRl5Q6brWkPDkaxRzjCgM7JF8HXRIZnfs1ubvmIA_OhwYwmdthSXyGsJ8CP8qQ0x0i82qbzlehNzuVtefSeHc=@toaster.cc' \
--to=angus@toaster$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=moth_oshi@proton$(echo .)me \
/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