From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
Date: Wed, 14 May 2025 15:54:55 +0000 [thread overview]
Message-ID: <qps_M7VTLROH7U1v1n_5snfjf-H-Gl-BX-V9qc1JSzzyqfsRoPrbaCzQAQFa1pU4w0cfXZHVnUta6Z7UryG1hUhtpcGXw1ZHiHOfl3HR2jo=@protonmail.com> (raw)
In-Reply-To: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]
Hi,
This proposal was heavily mediatized, and severe mischaracterizations of the change being proposed led to genuine concerns among the community. A better communication from my part could have avoided unnecessary worries among bitcoiners and a lot of wasted time to everybody.
In an attempt to right this wrong, i have collected objections community members have raised across the board (on Github, the Bitcoin development mailing list, X, podcasts, at conferences, ..) to address them in a single post.
I just posted to Delving Bitcoin addressing all concerns and objections i could get my hands on: https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697. These are actual objections and concerns raised by community members, taken literally with little or no reformulation to address the precise statement.
Antoine Poinsot
On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <darosior@protonmail•com> wrote:
> Hi,
>
> Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide upgrade hooks, or as a nudge to deter some usages.
>
> Bitcoin Core will by default only relay and mine transactions with at most a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. This standardness rule falls into the third category: it aims to mildly deter data storage while still allowing a less harmful alternative than using non-provably-unspendable outputs.
>
> Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
>
> Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.
>
> Antoine Poinsot
>
> [^0]: See section 6.1 of their whitepaper here https://citrea.xyz/clementine_whitepaper.pdf
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/qps_M7VTLROH7U1v1n_5snfjf-H-Gl-BX-V9qc1JSzzyqfsRoPrbaCzQAQFa1pU4w0cfXZHVnUta6Z7UryG1hUhtpcGXw1ZHiHOfl3HR2jo%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 5513 bytes --]
prev parent reply other threads:[~2025-05-14 15:56 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
2025-04-30 15:37 ` Nagaev Boris
2025-04-30 16:30 ` Sjors Provoost
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-05-01 17:40 ` Andrew Toth
2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
2025-05-01 19:33 ` Nagaev Boris
2025-05-02 6:34 ` Anthony Towns
2025-05-02 18:29 ` Peter Todd
2025-05-03 5:14 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-01 3:01 ` Anthony Towns
2025-05-02 18:56 ` Greg Tonoski
2025-05-05 6:04 ` Bitcoin Error Log
2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-02 0:14 ` PandaCute
2025-05-02 11:16 ` [bitcoindev] " Sjors Provoost
2025-05-02 14:37 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-02 16:43 ` Greg Maxwell
2025-05-02 13:58 ` [bitcoindev] " Bob Burnett
2025-05-02 20:03 ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
2025-05-02 22:58 ` [bitcoindev] " Greg Maxwell
2025-05-03 2:02 ` Martin Habovštiak
2025-05-05 21:45 ` Peter Todd
2025-05-05 23:55 ` Greg Maxwell
2025-05-25 15:53 ` waxwing/ AdamISZ
2025-05-20 16:26 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-20 23:12 ` Greg Maxwell
2025-05-21 2:10 ` Bob Burnett
2025-05-21 7:41 ` [bitcoindev] " Sjors Provoost
2025-05-21 13:38 ` Bob Burnett
2025-05-21 14:47 ` Pieter Wuille
2025-05-21 17:19 ` Bob Burnett
2025-05-21 17:52 ` Pieter Wuille
2025-05-21 18:12 ` Bob Burnett
2025-05-02 6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell
2025-05-02 9:51 ` Anthony Towns
2025-05-02 17:36 ` Greg Maxwell
2025-05-05 9:18 ` Anthony Towns
2025-05-05 21:34 ` [bitcoindev] Weak blocks give an advantage to large miners Peter Todd
2025-05-06 8:56 ` Sjors Provoost
2025-05-07 20:42 ` James O'Beirne
2025-05-02 20:43 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
2025-05-04 20:04 ` Nagaev Boris
2025-05-05 11:42 ` Greg Maxwell
2025-05-05 14:32 ` Nagaev Boris
2025-05-05 21:30 ` Peter Todd
2025-05-05 14:05 ` Greg Maxwell
[not found] ` <20250502064744.92B057C0EE2@smtp.postman.i2p>
2025-05-07 1:20 ` pithosian
2025-05-07 11:32 ` Greg Maxwell
[not found] ` <20250507121109.6CEA77C0AAF@smtp.postman.i2p>
2025-05-07 16:55 ` pithosian
2025-05-12 13:47 ` [bitcoindev] " Anthony Towns
2025-05-14 15:54 ` 'Antoine Poinsot' via Bitcoin Development Mailing List [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='qps_M7VTLROH7U1v1n_5snfjf-H-Gl-BX-V9qc1JSzzyqfsRoPrbaCzQAQFa1pU4w0cfXZHVnUta6Z7UryG1hUhtpcGXw1ZHiHOfl3HR2jo=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
/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