Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man)

[Greg Maxwell <gmaxwell@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4055 bytes --]

On Tue, Jun 3, 2025 at 8:00 AM Sjors Provoost <sjors@sprovoost.nl> wrote:

> Then all you've achieved is an incentive to submit directly to miners,
> making those miners more profitable. Congrats, you didn't fix spam, you
> didn't rate limit anything and you made mining more centralised.
>

That's not all it does: it also created infrastructure for impeding other
kinds of transactions which may be much more time sensitive than the spam
transactions and may be much less able to use direct submission.

No one is going to (convincingly) argue that including a monkey jpeg in a
transaction is _unlawful_ and so for commercial miners there is always
going to be a price where they will include them-- and that price is lower
once excessive filtering pays for the creation of submission mechanisms (as
it already has done).

But when the censorship is backed by threat (even if vague or
unconstitutional) of civil or criminal legal penalties, the avenue to just
bypass may be much less available.

So for example, in an alternative universe: Bitcoin goes along with Guida
and after having built this massive edifice of transaction censorship the
Bitcoin developers lose their UK lawsuit Craig S Wright after he
successfully bribes a judge, and now have a the UK courts imposing a
worldwide order to freeze any of their bitcoin address under threat of
imprisonment.  The censorship is deployed via the prebuilt censorship
infrastructure, and willingness to bypass it is greatly decreased because
doing so would land the bypasser a UK arrest warrant. Could they still get
their transactions through?  Probably but at much greater costs and delays,
creating a significant harm.  Not building the censorship infrastructure
(even though you intend it for 'good' purposes) and instead building
anti-censorship infrastructure leaves us all with a better world.

A world that, sure, sometimes has higher transaction fees due to waves of
well funded spam--- but that's just the cost of having limited capacity on
the network to preserve the ability to validate and to provide income for
security.  It's not a cost of spam itself:  Even if there was never any
spam at all there would sometimes be elevated transaction fees due to
surges in demand.  Essentially the energy behind this anti-spam stuff is
just relitigating the blocksize war, but doing it under the cover(?) of
undermining a foundational property of Bitcoin: that bitcoin was created to
escape other people passing judgement over which existing transactions are
okay or not.  The Bitcoin project has never seen that to be its role.

Prior to Bitcoin your ability to transact "could always be overridden by
the admin based on his judgment call weighing the principle [...] against
other concerns, or at the behest of his superiors."  If someone cares that
someone else is using bitcoin for things they don't like, or that being
outbid can delay their transactions-- then they ought to be using something
else.  This was settled long ago.

That's the problem with all this filtering stuff:  It works better, to the
extent it works at all, against sincere usage which lacks the flexibility
of spam (or outright attacks).  Sincere usage cares that the network
validates its rules, it has to spend specific coins, specific values, use
specific fields.   Collateral usage (a term that I think better captures
most of what people are calling spam)-- where the goal of the transaction
isn't really to move Bitcoins-- can do virtually *anything* with its
transactions, it is far more flexible and so it is less vulnerable to
attempts to filter it.

-- 
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/CAAS2fgT3gyra4BNN1zDVz%3Dn%3DtmteZLC4xuzTWSm_s0T6Rw2MJA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5353 bytes --]