From: Greg Maxwell <gmaxwell@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Fri, 2 May 2025 09:43:05 -0700 (PDT) [thread overview]
Message-ID: <f19214a4-6a89-4a2f-a729-560d244573bfn@googlegroups.com> (raw)
In-Reply-To: <s0wjN-XWg2inZbTjDilS4QsIddAa6sP7Zo7xp2XxcheO1d21g-7Jy_-okj96LPEBSAV1BtoEnrIKzgZLi06c1aka0kvFiR3l0YqxYxuTHRQ=@pm.me>
[-- Attachment #1.1: Type: text/plain, Size: 3442 bytes --]
On Friday, May 2, 2025 at 3:28:36 PM UTC nsvrn wrote:
"Spam is annoying but it always runs it course if you ignore it"
and
"When relay policy shouldn't be more restrictive than what is actually
being mined"
are contradictory statements by gmaxwell. Btw, 99.9% of transactions rn are
standard, nothing has changed. People are pre-emptively making accomodation
for a startup with a whitepaper. No one is making relay policy more
restrictive, they're talking about making it more flexible "pre-emptively".
I've looked high and low and I can't find any case where I've made the
first quotation. Can you help me out? It sounds like a riff on views I
expressed but I can't find it.
I think your comparison though demonstrates a downside of reasoning in
broad categories. High volume nuisance traffic tends to burn itself out
because the user that is flooding out everyone else has to burn whatever
everyone else was willing to pay in each block everyone else is displaced
from-- they run out of money. But my statement on relay policy doesn't
have much to do with volume. A small consistent _small_ stream of
transactions that aren't getting relayed but get mined anyways brings the
downsides of having a mining inconsistent relay policy, there doesn't need
to be a flood. And no flood, no self limiting behavior in any case.
I also think your argument misses the mark in that there isn't a credible
argument that there is/will-be any traffic floods that the
proposed-for-removal criteria will *prevent*. Anyone who wants to stuff
data into outputs can already stuff an unlimited amount, there are parties
right now who are currently doing so. Moreover, there is no credible way
to stop them from doing so (because you can't distinguish arbitrary data
from addresses, essentially). However, if they use OP_RETURN instead it
will prevent the data from going into the UTXO set. Maybe they will maybe
they won't. But counting this proposal with concerns about 'spam' doesn't
get us anywhere because removing the restriction doesn't change the current
situation with respect to 'spam' however you define it.
It doesn't really matter how dire spam is when discussing a proposal that
doesn't meaningfully *change* the situation around it, except perhaps in
giving a lever to convert some more harmful traffic into less harmful
traffic. If it did then sure the harms of the spam would be a relevant
consideration.
> People are pre-emptively making accomodation for a startup with a
whitepaper
I can't speak for others but I didn't follow any links related to citrea or
any other startup in the thread, I don't think it's relevant. I have been
complaining about standardizes rules screwing up block reconstruction and
direct to miner relationships to bypass relay rules for several years. My
impression is that random startup whatever carries precisely zero weight in
minds of the vast majority of the commenters in favor of eliminating the
restriction.
--
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/f19214a4-6a89-4a2f-a729-560d244573bfn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3991 bytes --]
next prev parent reply other threads:[~2025-05-02 19:09 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 '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-01 3:01 ` Anthony Towns
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 [this message]
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-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-02 20:43 ` Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
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=f19214a4-6a89-4a2f-a729-560d244573bfn@googlegroups.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.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