path: root/a2/a6347367411ae3e99f61ee3ecc961c756f4012

Delivery-date: Wed, 30 Apr 2025 22:20:45 -0700
Received: from mail-oo1-f57.google.com ([209.85.161.57])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDSKF7WH24FRBIEJZTAAMGQERU27REQ@googlegroups.com>)
	id 1uAMLj-0005GQ-Q1
	for bitcoindev@gnusha.org; Wed, 30 Apr 2025 22:20:45 -0700
Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-603f8bab77csf1203850eaf.0
        for <bitcoindev@gnusha.org>; Wed, 30 Apr 2025 22:20:43 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746076838; cv=pass;
        d=google.com; s=arc-20240605;
        b=jQh92nr5iVnfIKsI8jq8dhtdvWkvbL9kbcz4LQzFzYwhqiHD+BQHetHv5JW6T3UlSQ
         F8RNZI5Igiog2YhPyPcxWNoWONkQozqbel346uawxNJ/jBRt1bTT/4ueiv6vCsor0CV0
         jMwFLOLcR8X0Vzxw4rPAzXpaP2npZYRDKWA6eaVwJHo2eBTzuHrISw9USGiq3heIolXF
         yLVTJUPVyw6zZA0gUbTFwFBVZ+NXuID07lLh5EVk9++YKiys+vreSGZZweAgBNW+yFbc
         tTpyQJ0S2hbsBzKM4cVgBO9EL8zDufEkGRVGVLlMbb0wKVGI6SfaEQ11YGXk/FBZ+xEX
         FchA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=lYWWF8wOAEYjaqkO7UBVuZ0jArNnzpTJ9gxS+V+WITE=;
        fh=N7gTzlGSRFWR5qa9eXNqDiQwFY7L0vUyy3x96Akjjvs=;
        b=JCAAYOehtzurj9lE5z9doUsAfQ0NZEkXJmzlocFUNUHTQlDO02PLNydcywVtzjtW2V
         /gwrBxuYalMuNy2RlvQSmsE04PRtOr0HiffMK3nN+2onDGeojcpX+4bXW7oIbOOWomhf
         5hL3ip2aOoWHVy2fdwb6Qy4RVlxeQvYIJID74nV58XtQWThHqP3vLQnFgHAFpkXNNx//
         noLFAJffF7MrlyxQEvSvBwy21hSByv997DsKsMfZYgwjsW2og9vVgTsgJtw76n67HCTd
         yOiIHMxONu5h1jmHtyOYtfvjM8aX6WxKAkR0eeKy+LSCDLofUu8kgyYAg490BG18hPku
         5Luw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=MqOU1L1k;
       spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) smtp.mailfrom=chrisguida@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746076838; x=1746681638; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=lYWWF8wOAEYjaqkO7UBVuZ0jArNnzpTJ9gxS+V+WITE=;
        b=PVOsSCjEdcTgjCfs+yhZDkzhmgGCaUcAmBF12zs1+2E7QKWdAGZ9DuDlnNtXUD0dgP
         vtSOCHV7fBNmLjFXGn67PO4gZe5YBiB0WGK8nqt+O3kttPclP74epMb9iwG+iCOLxI4F
         yYDYJwT+L436snfHhRSaEujDZTclDhmuC+CHV0y/4CCnbhdy0nFcH/qxaeHbepi0e1je
         WniF2gx5zviPmL++i5OsA0FAuPotEKkN8Wuq69yitfZ1LUFELLKSJ0PkZ/m64Sa8ouxC
         RnXPugC/rsSfX7i1o1Moh+dBc5SHEdA1PKphwb4f3SYJwaH1REJS32aiktxLfyEuJaNr
         PLIQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746076838; x=1746681638; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=lYWWF8wOAEYjaqkO7UBVuZ0jArNnzpTJ9gxS+V+WITE=;
        b=EQ2v9sQq69ra2+OY4qHnNIBwyyOdsBrCByG3LX1zCb7Jr2iDZIYXu0kFK/12G9ihZv
         gv+dJueCpPc5f/jdLbUa7K/QmRPfg8F8sjx5QkSfT6syWNn8iFgBmy50zuvqLbZ+H52A
         R630n3mTXHrmA+yW4aotDix863Zy1CUIJoskFEBRpyqVZt72niKAIn84qMLZTkv7a8NO
         SLPYq9kk8JqsAg7cSFfL8Zn5xU8TjpPVkqBQ4ddQqbESdfQYAQuIsnlzAy55gzcJA6eY
         IqZpvu5GcEdpnAVWt+dEv9PFmHS1dUxkE9a7LDIjovbEqPbQbfpEPP75TDKs5Ww0qi9y
         xQ8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746076838; x=1746681638;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=lYWWF8wOAEYjaqkO7UBVuZ0jArNnzpTJ9gxS+V+WITE=;
        b=Lwuxw+QZ1/ykP/tzCjRFOPU5hlG+YSmm+Hbp8NeMyhZ5SD+voQ7w3lHYloLMN2tfDW
         VhzuPQzOjzXLSVJjoK05hr9n+UZ3ETbimfm3NJkJXEN6Se6iWLsN9k0J18wN10ms4zWa
         sNCVCMPpsA+ftxmx9HFQureNz8mUj1CPjja0wkdlgR9Tzqhpi/wcIkv6cu7vti0Doae6
         CAfxBldlT+dhX3y1WARORWfEtIsYCFK4pPr+0td//u8i0UW6rYBJSDONCYtqpXCPZczm
         eACThcB9TvT2RMnUJneU6gGxB4zPAK63A0UJQpwQdJrkk3uxLUBAD34WEUqy6u9BQREZ
         hMyQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUEpPQyD8o2e0f3J9BPrCeds2OKmgZfj/H0caFU39u3Bk6bL6lPcU/FaF6M/Yb4ADRA2fQMZpC77ucK@gnusha.org
X-Gm-Message-State: AOJu0Yx3jyx0Ev9j/DHngtHQ5o+qyPD6yv9mQEETEuNNhcaamzMLYwWe
	HwjIblfdpDftoTDMlSBCb4G4S4Pf9zwKkHHRS+Trh8P/A+EB5U6p
X-Google-Smtp-Source: AGHT+IECNpaxEzFdYdDCBxJLItvfTgTFSCO3xPIG16qxX2WxfFeo6Qa7SKW4U9q9TpWple4T3eyRPQ==
X-Received: by 2002:a05:6820:88b:b0:604:99a6:4e90 with SMTP id 006d021491bc7-607e2043af1mr486746eaf.0.1746076837618;
        Wed, 30 Apr 2025 22:20:37 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHHHFT7aL4E/iYPNLGOtKbCi83DR7Jj5w6Ixs0VpzZH9Q==
Received: by 2002:a4a:c993:0:b0:607:d2b6:5fdf with SMTP id 006d021491bc7-607df412ee5ls208750eaf.2.-pod-prod-00-us;
 Wed, 30 Apr 2025 22:20:32 -0700 (PDT)
X-Received: by 2002:a05:6808:1c0f:b0:3f6:a851:fe85 with SMTP id 5614622812f47-4033649a677mr399526b6e.14.1746076832461;
        Wed, 30 Apr 2025 22:20:32 -0700 (PDT)
Received: by 2002:a05:6808:1595:b0:3fa:da36:efcd with SMTP id 5614622812f47-40335daa698msb6e;
        Wed, 30 Apr 2025 21:59:18 -0700 (PDT)
X-Received: by 2002:a05:6808:6f8c:b0:400:e771:ab80 with SMTP id 5614622812f47-4033619d07dmr497764b6e.0.1746075558178;
        Wed, 30 Apr 2025 21:59:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1746075558; cv=none;
        d=google.com; s=arc-20240605;
        b=LDiUV2pBJKK8bH2pDYXd7ydLAYlGPQNejz9MUzl926AhkA/S6yVbp7kC17/5nBT8yR
         zwYdBZnNq1qX88WxGS4ad37i7pxxdxL0zHsRmK+TFz3RUPJeIvsi4VtNx8csaKRIXLqZ
         wWnV5Fme7NJrP3nOBSElLxFHLRGuwDYjgsFVe+VtufbLjWN5+Vkq2pRer0ZFXdJpijL3
         emdXw6Dziwnp/33akFrenyfdCsjT2pbqXTXJ+q+EAZOnmOHwfVFtqoQSghzqpqpDlbzO
         lQ/z3m1uM7v4/qNmvfjKFlTIqd55KaOSW0BlRXK8PjJ0+/MBCGX7Dc6ROBF3FAfzxgTW
         /lhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=afx59Q1+qfP/rdDHaQgbuIiqIoLmlCBSb+78on8NHo4=;
        fh=eQwyrPB7DiKLZfk3HA1+IBNTG62m+FxzJ3AFq+zftRc=;
        b=ClA+7QVwleAc0dBb+aFvMhwNPg2qnQU0VcsoNY9dBwsu8Iv/CFaOcjypDlUbsEVWlC
         TQ3C6UT8/putjRKvWvT9bE9x2kcUqWu28N8w8v0/xf+Prj1pCnP/z6cgnhhcHQ8kx8FU
         JSESy5wVLBiSu+rPNruAJ7AjAHYM+sNbMwHOGPFGgg5i42s3StSAg7s90vWDHUQI67pf
         X7bVoK9DtohdH4Sji22+xXwRN0woD0C5JSO5kZYTvLbdRvQV9K2OSelufpsLA2caAgZ1
         XH7FfoFv1Zy/drtXjAAmyE6yW696KGfw0Cxu4A09cRsXeES1FShLCww6HjLnqxIJ1vyV
         OrzA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=MqOU1L1k;
       spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) smtp.mailfrom=chrisguida@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com. [2607:f8b0:4864:20::f36])
        by gmr-mx.google.com with ESMTPS id 5614622812f47-40212c4bf39si245821b6e.5.2025.04.30.21.59.18
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 30 Apr 2025 21:59:18 -0700 (PDT)
Received-SPF: pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) client-ip=2607:f8b0:4864:20::f36;
Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6ecf0e07947so7318066d6.0
        for <bitcoindev@googlegroups.com>; Wed, 30 Apr 2025 21:59:18 -0700 (PDT)
X-Gm-Gg: ASbGncsr9cNhc5cLUv99pRKBEFFhSXiGQEo/ptHxzhAJ2a0X+7GPg2vbbAx43wS0UtA
	ly1BnZxITlcYB4FX7/rTld8XWX3J2ASRS++InwUksdEctIvS6Lsa23g1DRfR66kXElSxeVhCYRA
	I0Pu2Ur9zNYlwMEp/bLNayNKBjfAnOOqvp7l9EQBLRzup30E0TBHi9mFw=
X-Received: by 2002:a05:6214:5018:b0:6e4:3478:8ea7 with SMTP id
 6a1803df08f44-6f50b8ea69amr16135366d6.4.1746075557492; Wed, 30 Apr 2025
 21:59:17 -0700 (PDT)
MIME-Version: 1.0
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org> <CEB83B34-6C5B-469E-9914-20940F27EEC0@sprovoost.nl>
 <d18b4149-5523-44bd-8332-2b7962f4b674@dashjr.org> <QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net>
 <f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com> <CALkkCJY5T5sd5Am0M6abhaMMicwVNvSfwYQP1jMjxfVsuT8Jaw@mail.gmail.com>
 <CAAANnUy08NBOq3B++80Rpna2qkD6NJV9RdV9v0Oi8c3G8eq_4g@mail.gmail.com> <aBJR3YHgHrycPfAp@erisian.com.au>
In-Reply-To: <aBJR3YHgHrycPfAp@erisian.com.au>
From: Chris Guida <chrisguida@gmail.com>
Date: Wed, 30 Apr 2025 22:57:29 -0600
X-Gm-Features: ATxdqUF4QxDh7ea3ulZ5kYtjKSXWCRnzrHyOZCGhO0BPtd_jXWvEoFbBqjLCVPA
Message-ID: <CAAANnUxnEfO7VexaK_V+Rc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q@mail.gmail.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
To: Anthony Towns <aj@erisian.com.au>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000005afad206340be506"
X-Original-Sender: ChrisGuida@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=MqOU1L1k;       spf=pass
 (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36
 as permitted sender) smtp.mailfrom=chrisguida@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--0000000000005afad206340be506
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM 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
>
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAAANnUxnEfO7VexaK_V%2BRc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q%40mail.gmail.com.

--0000000000005afad206340be506
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi AJ, thanks for the feedback.</div><div><br></div><=
div>&gt;Fees are under 3sat/vb; there&#39;s no attack. Excess block space i=
s being<br>
filled by low-value spam, but that&#39;s expected and, in a permissionless<=
br>
system, unavoidable.</div><div><span class=3D"gmail-im"><br></span></div><d=
iv><span class=3D"gmail-im">This is just a temporary cease-fire while the s=
pammers reload their ammunition. There is obviously about to be another wav=
e, otherwise what is the point of eliminating OP_RETURN restrictions?</span=
></div><div><span class=3D"gmail-im"><br></span></div><div><span class=3D"g=
mail-im">&gt;</span>They subside when the people creating the spam realise =
they&#39;re wasting<br>
money paying for fees.</div><div><br></div><div>Yes, and then the money pri=
nter makes sure that there is always enough easy money sloshing around in t=
he economy so that more pop up where the old ones dropped out. This can and=
 will continue indefinitely if we do nothing.</div><div><br></div><div>&gt;=
Acting tough about it at best has zero effect, and at worst generates<br>
publicity for the spammers as media and influencers gather around the<br>
drame, making the activity more profitable.</div><div><span class=3D"gmail-=
im"><br></span></div><div><span class=3D"gmail-im">It worked great in 2014!=
</span></div><div><span class=3D"gmail-im"><br></span></div><div><span clas=
s=3D"gmail-im">&gt;</span>Encoding data into random protocols is a standard=
 exercise, and doing<br>
so in ways that are undetectable to third parties is also standard,<br>
albeit more complicated. In a permissionless system, attempting to<br>
filter encoded data is a losing proposition.</div><div><br></div><div>&gt;W=
ell, I guess if you can convince someone to pay you by the hour to write<br=
>
the filters, you&#39;ve got yourself a job that will never be finished,<br>
so really it&#39;s only a losing proposition if you ever hope to actually<b=
r>
succeed at it.<span class=3D"gmail-im"><br></span></div><div><br></div><div=
>You seem to have only read about half of my message. I guess I should have=
 written something shorter!</div><div><br></div><div>I&#39;ll repeat the re=
levant part here in case you missed it:</div><div><br></div><div>&quot;We d=
on&#39;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=20
the spammers, and the worst schemes (the ones that rely on a consistent=20
transaction format) will be impossible to maintain, and will therefore=20
lose funding. Of course there will be hobbyist spammers here and there,=20
but that&#39;s much less damaging.&quot;</div><div><br></div><div>My propos=
al is not to counter literally every type of spam. Just the ones that have =
protocols relying on consistent transaction formats. Creating specific filt=
ers against just these worst offenders should be a strong deterrent against=
 creating more of them. This class of spam requires coordination among a lo=
t of people to choose and promote a stable format, so disrupting their form=
ats with targeted filters should have them fleeing to other chains in no ti=
me. 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!<br></div><div>=
<br></div><div>&gt;Not every form of transaction spam is about jpegs or alt=
coins.</div><div><br></div><div>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 mention=
ed.</div><div><br></div><div>And of course, smaller blocks don&#39;t help w=
ith <i>high</i>-value (high-fee) spam, which the recent ordinals/runes wave=
s 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 s=
tuff. (Lightning helps somewhat with this if you already have a channel, bu=
t if you don&#39;t it&#39;s very painful, and onboarding new bitcoiners to =
Lightning during these fee spikes is terrible.)</div><div><br></div><div>Be=
st regards,</div><div><br></div><div>--Chris<br></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Wed, Apr 30, 2025 at 10:37=E2=80=AFAM Anthony Towns &lt;<a href=3D"mai=
lto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">On Tue, Apr 29, 2025 at 11:39:01PM =
-0600, Chris Guida wrote:<br>
&gt; We are under a spam attack.<br>
<br>
Fees are under 3sat/vb; there&#39;s no attack. Excess block space is being<=
br>
filled by low-value spam, but that&#39;s expected and, in a permissionless<=
br>
system, unavoidable.<br>
<br>
&gt; This is not the first time this has happened.<br>
&gt; Bitcoin has endured several spam attacks in the past. They subside whe=
n<br>
&gt; bitcoin core devs show that they are serious about countering the atta=
cks.<br>
<br>
They subside when the people creating the spam realise they&#39;re wasting<=
br>
money paying for fees.<br>
<br>
Acting tough about it at best has zero effect, and at worst generates<br>
publicity for the spammers as media and influencers gather around the<br>
drame, making the activity more profitable.<br>
<br>
&gt; Unfortunately, the bitcoin core project made a misstep when it rejecte=
d<br>
&gt; this PR[3] from Luke-jr to filter transactions using the op_false op_i=
f<br>
&gt; envelope to exploit the witness discount.<br>
<br>
Encoding data into random protocols is a standard exercise, and doing<br>
so in ways that are undetectable to third parties is also standard,<br>
albeit more complicated. In a permissionless system, attempting to<br>
filter encoded data is a losing proposition.<br>
<br>
Well, I guess if you can convince someone to pay you by the hour to write<b=
r>
the filters, you&#39;ve got yourself a job that will never be finished,<br>
so really it&#39;s only a losing proposition if you ever hope to actually<b=
r>
succeed at it.<br>
<br>
&gt; Another trope from the anti-filter crowd I keep seeing is that spam<br=
>
&gt; protection is a &quot;cat-and-mouse&quot; game. Well, the cat won in 2=
014 and the<br>
&gt; mouse didn&#39;t come back until 2023.<br>
<br>
Not every form of transaction spam is about jpegs or altcoins. There<br>
were significant spam attacks on the network in 2015, see<br>
<br>
<a href=3D"https://en.bitcoin.it/wiki/July_2015_flood_attack" rel=3D"norefe=
rrer" target=3D"_blank">https://en.bitcoin.it/wiki/July_2015_flood_attack</=
a><br>
<a href=3D"https://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-s=
eptember-create-30-day-transaction-backlog-1515981" rel=3D"noreferrer" targ=
et=3D"_blank">https://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attac=
k-september-create-30-day-transaction-backlog-1515981</a><br>
<a href=3D"https://nyuscholars.nyu.edu/en/publications/stressing-out-bitcoi=
n-stress-testing" rel=3D"noreferrer" target=3D"_blank">https://nyuscholars.=
nyu.edu/en/publications/stressing-out-bitcoin-stress-testing</a><br>
<br>
eg. The spam during that time was particularly harmful, because most<br>
wallets failed to calculate fees on a per-vbyte basis and replace-by-fee<br=
>
was rarely supported, leading to many transactions getting stuck in the<br>
mempool for weeks or months as a result.<br>
<br>
The only sustainable way to avoid low value spam appearing on the<br>
blockchain (whatever form that spam might take) is to prevent low value<br>
*transactions* from appearing on the blockchain. I don&#39;t think that&#39=
;s<br>
particularly desirable at this time; but it&#39;s something that could be<b=
r>
achieved (even on a temporary basis) by lowering the block size.<br>
<br>
Cheers,<br>
aj<br>
<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAANnUxnEfO7VexaK_V%2BRc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAAANnUxnEfO7VexaK_V%2BRc1ZG8tO1pLAU0gsDJb8C82hiwgQ-Q%40ma=
il.gmail.com</a>.<br />

--0000000000005afad206340be506--