From: Anthony Towns <aj@erisian•com.au>
To: Chris Guida <chrisguida@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Fri, 2 May 2025 16:34:45 +1000 [thread overview]
Message-ID: <aBRnhXwUYWFbvd95@erisian.com.au> (raw)
In-Reply-To: <CAAANnUxnEfO7VexaK_V+Rc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q@mail.gmail.com>
On Wed, Apr 30, 2025 at 10:57:29PM -0600, Chris Guida wrote:
> > Fees are under 3sat/vb; there's no attack. Excess block space is being
> > filled by low-value spam, but that's expected and, in a permissionless
> > system, unavoidable.
> This is just a temporary cease-fire
I mean, the definition of a cease-fire is that no one attacks during it.
> while the spammers reload their
> ammunition. There is obviously about to be another wave, otherwise what is
> the point of eliminating OP_RETURN restrictions?
The point of eliminating OP_RETURN restrictions is to avoid people
encoding data in more harmful ways.
> > They subside when the people creating the spam realise they're wasting
> > money paying for fees.
> Yes, and then the money printer makes sure that there is always enough easy
> money sloshing around in the economy so that more pop up where the old ones
> dropped out. This can and will continue indefinitely if we do nothing.
Yes, spammers can and will continue filling up block space if they're
willing to pay more for that block space than non-spammers.
> > Acting tough about it at best has zero effect, and at worst generates
> > publicity for the spammers as media and influencers gather around the
> > drama, making the activity more profitable.
> It worked great in 2014!
I don't agree with that claim. (To be specific: I think it had zero
technical/economic effect (though maybe some propaganda value), and that
Ethereum was launched as its own chain for the same class of reasons
that Algorand and Solana launched their own chains, rather than using
data commitments on top of Ethereum)
> You seem to have only read about half of my message. I guess I should have
> written something shorter!
It's almost always true that writing something shorter is better.
> I'll repeat the relevant part here in case you missed it:
> "We don't need to make sure no spam ever reaches the blockchain. That is,
> of course, impossible. All we need to do is show active hostility to the
> spammers, and the worst schemes (the ones that rely on a consistent
> transaction format) will be impossible to maintain,
Ultimately, that's not true: you can always encode data in ways that would
otherwise look like a normal financial transaction, or a set of normal
financial transactions, and if necessary, encrypt it in a way that it's
only identifiable as a data encoding after it's already been published.
I don't particularly want to give practical examples of how to do that,
of course.
> And of course, smaller blocks don't help with *high*-value (high-fee) spam,
> which the recent ordinals/runes waves were.
Ordinals/runes only managed to have fees-per-block rise above the block
subsidy (ie 313sat/vb or 625sat/vb) for a handful of blocks, so I wouldn't
call it particularly "high value" in general. At 3sat/vb and $100k/BTC
we're still at the "sure, I can afford 25c for an on-chain tx to buy a
coffee" level.
> My worry with high-value spam
> is that if it keeps growing, it could make it practically impossible for
> people to just use bitcoin to pay for stuff.
That's the exact opposite concern: if there's that much high value
transaction volume, then that valuation will justify paying for both
engineering talent to avoid whatever filtering efforts you come up with
(if nothing else, by spammers mining blocks directly), and mining fees to
price your transactions out of the available block space. The solution to
that scenario is to increase the block size, until there's enough capacity
for all the high value transactions as well as your lower value ones.
I don't share that concern, personally. Data storage is far more
efficiently done outside of a blockchain (or more cheaply done on
non-Bitcoin blockchains), and for any legitimate use case, avoiding
wasting money on inefficient designs or unnecessary engineering projects
lets you capture more of that value as profit. For scams and frauds,
that doesn't apply, but scams and frauds only last until your pool of
victims grows wise to your shenanigans.
Cheers,
aj
--
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/aBRnhXwUYWFbvd95%40erisian.com.au.
next prev parent reply other threads:[~2025-05-02 6:49 UTC|newest]
Thread overview: 35+ 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 [this message]
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
2025-05-02 13:58 ` [bitcoindev] " Bob Burnett
2025-05-02 6:29 ` Greg Maxwell
2025-05-02 9:51 ` Anthony Towns
2025-05-02 17:36 ` Greg Maxwell
2025-05-02 19:04 ` /dev /fd0
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=aBRnhXwUYWFbvd95@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.com \
--cc=chrisguida@gmail$(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