From: Chris Guida <chrisguida@gmail•com>
To: Anthony Towns <aj@erisian•com.au>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Wed, 30 Apr 2025 22:57:29 -0600 [thread overview]
Message-ID: <CAAANnUxnEfO7VexaK_V+Rc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q@mail.gmail.com> (raw)
In-Reply-To: <aBJR3YHgHrycPfAp@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 6891 bytes --]
Hi AJ, thanks for the feedback.
>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 while the spammers reload their
ammunition. There is obviously about to be another wave, otherwise what is
the point of eliminating OP_RETURN restrictions?
>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.
>Acting tough about it at best has zero effect, and at worst generates
publicity for the spammers as media and influencers gather around the
drame, making the activity more profitable.
It worked great in 2014!
>Encoding data into random protocols is a standard exercise, and doing
so in ways that are undetectable to third parties is also standard,
albeit more complicated. In a permissionless system, attempting to
filter encoded data is a losing proposition.
>Well, I guess if you can convince someone to pay you by the hour to write
the filters, you've got yourself a job that will never be finished,
so really it's only a losing proposition if you ever hope to actually
succeed at it.
You seem to have only read about half of my message. I guess I should have
written something shorter!
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, and will therefore lose
funding. Of course there will be hobbyist spammers here and there, but
that's much less damaging."
My proposal is not to counter literally every type of spam. Just the ones
that have protocols relying on consistent transaction formats. Creating
specific filters against just these worst offenders should be a strong
deterrent against creating more of them. This class of spam requires
coordination among a lot of people to choose and promote a stable format,
so disrupting their formats with targeted filters should have them fleeing
to other chains in no time. Conveniently for us, this class of spam is also
the riskiest to create, since it usually involves investing money upfront
to launch the Ponzi. If the launch goes poorly because bitcoiners were not
accommodating, then the investors lose their money. The financial pain this
causes teaches a lesson that is usually remembered. Namely: to spam
somewhere else!
>Not every form of transaction spam is about jpegs or altcoins.
Thanks for pointing this out! Of course the strategy outlined above does
not apply to spam attacks that look like real financial activity. To
prevent utxoset/blockchain bloating in those cases, we will need something
more drastic, such as smaller blocks as you mentioned.
And of course, smaller blocks don't help with *high*-value (high-fee) spam,
which the recent ordinals/runes waves were. 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. (Lightning helps somewhat with
this if you already have a channel, but if you don't it's very painful, and
onboarding new bitcoiners to Lightning during these fee spikes is terrible.)
Best regards,
--Chris
On Wed, Apr 30, 2025 at 10:37 AM Anthony Towns <aj@erisian•com.au> wrote:
> On Tue, Apr 29, 2025 at 11:39:01PM -0600, Chris Guida wrote:
> > We are under a spam attack.
>
> 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 not the first time this has happened.
> > Bitcoin has endured several spam attacks in the past. They subside when
> > bitcoin core devs show that they are serious about countering the
> attacks.
>
> They subside when the people creating the spam realise they're wasting
> money paying for fees.
>
> Acting tough about it at best has zero effect, and at worst generates
> publicity for the spammers as media and influencers gather around the
> drame, making the activity more profitable.
>
> > Unfortunately, the bitcoin core project made a misstep when it rejected
> > this PR[3] from Luke-jr to filter transactions using the op_false op_if
> > envelope to exploit the witness discount.
>
> Encoding data into random protocols is a standard exercise, and doing
> so in ways that are undetectable to third parties is also standard,
> albeit more complicated. In a permissionless system, attempting to
> filter encoded data is a losing proposition.
>
> Well, I guess if you can convince someone to pay you by the hour to write
> the filters, you've got yourself a job that will never be finished,
> so really it's only a losing proposition if you ever hope to actually
> succeed at it.
>
> > Another trope from the anti-filter crowd I keep seeing is that spam
> > protection is a "cat-and-mouse" game. Well, the cat won in 2014 and the
> > mouse didn't come back until 2023.
>
> Not every form of transaction spam is about jpegs or altcoins. There
> were significant spam attacks on the network in 2015, see
>
> https://en.bitcoin.it/wiki/July_2015_flood_attack
>
> https://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-september-create-30-day-transaction-backlog-1515981
>
> https://nyuscholars.nyu.edu/en/publications/stressing-out-bitcoin-stress-testing
>
> eg. The spam during that time was particularly harmful, because most
> wallets failed to calculate fees on a per-vbyte basis and replace-by-fee
> was rarely supported, leading to many transactions getting stuck in the
> mempool for weeks or months as a result.
>
> The only sustainable way to avoid low value spam appearing on the
> blockchain (whatever form that spam might take) is to prevent low value
> *transactions* from appearing on the blockchain. I don't think that's
> particularly desirable at this time; but it's something that could be
> achieved (even on a temporary basis) by lowering the block size.
>
> 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/CAAANnUxnEfO7VexaK_V%2BRc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8805 bytes --]
next prev parent reply other threads:[~2025-05-01 5:20 UTC|newest]
Thread overview: 22+ 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-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida [this message]
2025-05-01 3:01 ` Anthony Towns
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=CAAANnUxnEfO7VexaK_V+Rc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q@mail.gmail.com \
--to=chrisguida@gmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--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