public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chris Guida <chrisguida@gmail.com>
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: Sjors Provoost <sjors@sprovoost.nl>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man)
Date: Wed, 4 Jun 2025 14:00:19 -0600	[thread overview]
Message-ID: <CAAANnUzBbzHcL_dajefUi5T57qvUeexPijAUBGVxywvRuosF4w@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgT3gyra4BNN1zDVz=n=tmteZLC4xuzTWSm_s0T6Rw2MJA@mail.gmail.com>

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

Hey Greg -

I certainly share your concerns about governments censoring bitcoin. We
should absolutely make sure we don't put bitcoin in a position where
governments might start to get ideas.

However, as I tried to argue in my response to Peter, I think being too
permissive with relay policy can be just as harmful as being too
restrictive. We must guide bitcoin through the Scylla of government
censorship and the Charybdis of making bitcoin's monetary function so
expensive and inconvenient that bitcoin simply ceases to be money. Avoiding
the latter catastrophe does not involve "censorship" at all. It involves
rate-limiting spam.

>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.

Can you elaborate on why you see this as a threat? Again, I don't see how
governments - even colluding worldwide - can compel 100% of the hashrate
not to mine transactions. The recent movement towards home mining seems to
make this outcome increasingly unlikely. But perhaps I am missing something?

>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.

Again, can you elaborate on how this attack would work? I don't understand
how the UK government, or anyone, could compel a large enough percentage of
hashpower not to mine transactions from certain actors for it to matter. If
bitcoin cannot stand up to tyrannical governments that try to impose unjust
(and in this case, impossible-to-enforce) demands, then what are we even
doing here?

>The censorship is deployed via the prebuilt censorship infrastructure

What is this "prebuilt censorship infrastructure" you refer to? Garbageman
is just a bitcoin node. No one is compelled to run it. It only makes a
difference if a large percentage of the bitcoin network is running it, and
this can only happen voluntarily. And again, it is impossible to use for
*censorship*. You are using that term incorrectly.

>and willingness to bypass it is greatly decreased because doing so would
land the bypasser a UK arrest warrant.

How does this even work? Are you saying that any noderunner who **doesn't**
run Garbageman could be compelled to do so? I'm just not seeing how this
could realistically be enforced.

>Could they still get their transactions through?  Probably but at much
greater costs and delays, creating a significant harm.

Can you go into more detail as to the harm caused? As Sjors pointed out,
people can just resubmit their transactions again and again if they fail to
be accepted the first time. And people can run LR nodes to get around
government *censorship*, if that's what's occurring. I completely agree
with the notion that LR could come in handy again if anyone *actually* ever
tries to censor bitcoin. In the case of a government attempting to
blacklist certain addresses, for example, it is very likely that LR would
see a surge in popularity and GM would not be as effective.

The noderunner network is decentralized. We need to trust that noderunners
will make the right choices and will run more GM nodes when spam is the
most pressing issue, and will run more LR nodes when censorship is top of
mind. I think each tool has its place. I just think we are nowhere near
LR's place currently, and I think it is a terrible idea *not* to build its
conservative counterpart, because then we will have no recourse once the
spam begins in earnest. And make no mistake, governments can attack bitcoin
via spam just as well as they can attack it via censorship. The loss of a
culture that values bitcoin's monetary function is just as deadly to
bitcoin as censorship would be.

>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.

I agree that building a "censorship infrastructure" would be a terrible
idea. That is not what Garbageman is. And again, I am fine with the
existence of LR, as there are (very unlikely) situations in which it could
come in useful. I just think at the moment we need fewer LR nodes, not
more. Censorship of bitcoin is exceedingly unlikely, whereas spam is the
much more pressing threat at the moment.

>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.

I disagree. We have successfully deterred spammers for almost a decade
between 2014 and 2023. If we treat them with the hostility they deserve,
then the economic demand for their activity drops precipitously. There is
hard historical data supporting this view. Conversely, if we throw open the
floodgates and welcome all the spammers in, now we've created economic
demand where previously there was very little.

>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.

This is inaccurate. I am not interested in relitigating the blocksize war.
I understand that block space needs to be limited to keep validation costs
low and the node network decentralized. I know this better than most, as
I've spent a large portion of the last few years setting up new users with
bitcoin nodes. In fact, this very property has been undermined by the spam
attack that happened during 2023-2024, where the minimum cost of hardware
sufficient to fully validate the chain in under a month went from $100 to
$250.

I am making a more nuanced point: If low-fee monetary activity is drowned
out by high-fee monetary activity, this is acceptable from the bitcoin
network's point of view, because *bitcoin is money*, and this simply
reflects that it is working properly. There are no threats to bitcoin's
culture if such a thing happens. Everyone simply goes on thinking that
bitcoin is money, and people who can't afford to pay high fees just wait
till the fees come back down. If, on the other hand, low-fee monetary
activity is drowned out by high-fee *non-monetary* activity, then this*
undermines bitcoin's entire identity and purpose as money* and corrupts its
culture into no longer believing that bitcoin is money at all, resulting in
a downward spiral ending in bitcoin's death by fading away into
irrelevance, just as we've seen with Ethereum.

>The Bitcoin project has never seen that to be its role.

I certainly hope the bitcoin project sees making sure bitcoin functions as
money as 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.

I completely agree that bitcoin is not interesting if it is not
permissionless *money*. If it is to be merely a permissionless *database*,
then it is no more interesting than Ethereum. So there are *two* ways in
which bitcoin can fail to be permissionless money and thus lose relevance:
too much censorship on the one hand, and too much spam on the other.

>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.

I don't agree with this view. As long as we detect Ponzi metaprotocols as
soon as they are announced, we can counter them without affecting sincere
usage. There are even proposals for modular filtering, where the bitcoin
node software would not even need a new release in order to counter a new
threat; filter developers could simply write new filters as the threats
evolve, and the node software could import it dynamically. In all
likelihood, once we implement this, the spammers will simply give up and
spam other chains instead.

There are certainly risks to implementing something like this, as it could
be co-opted to nefarious ends if we are not vigilant. However, as I stated
earlier, I think the noderunner network is sufficiently decentralized, and
noderunners themselves are smart enough about what software they run, that
the risk should be manageable. As long as there is no single point of
failure, I don't see much reason to be concerned. Again, everyone chooses
the software they run, and no one can be compelled to run something they
disagree with. I think we should trust noderunners to make the right
decisions.

Kind regards,

--Chris

On Tue, Jun 3, 2025 at 12:29 PM Greg Maxwell <gmaxwell@gmail.com> wrote:

> 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
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgT3gyra4BNN1zDVz%3Dn%3DtmteZLC4xuzTWSm_s0T6Rw2MJA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAAANnUzBbzHcL_dajefUi5T57qvUeexPijAUBGVxywvRuosF4w%40mail.gmail.com.

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

  reply	other threads:[~2025-06-09 10:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-27 11:16 [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man) Peter Todd
2025-05-27 11:37 ` John Carvalho
2025-06-03  2:52   ` Chris Guida
2025-06-03  6:50     ` Sjors Provoost
2025-06-03 17:00       ` Greg Maxwell
2025-06-04 20:00         ` Chris Guida [this message]
2025-06-05 12:16         ` Peter Todd
2025-06-03 17:41       ` Peter Todd
2025-06-03 17:51         ` Sjors Provoost
2025-06-03 20:32           ` Sjors Provoost
2025-06-04 18:44       ` Chris Guida
2025-06-05 13:29         ` Sjors Provoost
2025-06-03 17:58     ` Peter Todd
2025-06-04 20:16       ` Chris Guida
2025-06-05 11:59         ` Peter Todd
2025-06-06 17:38       ` Rijndael

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=CAAANnUzBbzHcL_dajefUi5T57qvUeexPijAUBGVxywvRuosF4w@mail.gmail.com \
    --to=chrisguida@gmail.com \
    --cc=bitcoindev@googlegroups.com \
    --cc=gmaxwell@gmail.com \
    --cc=sjors@sprovoost.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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