Censorship Resistant Transaction Relay - Taking out the garbage(man)
645 views
Skip to first unread message
Peter Todd
May 27, 2025, 7:23:09 AMMay 27
to bitco...@googlegroups.com
Recently proponents of transaction "filtering" have started sybil attacking
Libre Relay nodes by running nodes with their "garbageman" fork¹. This fork
falsely advertise the NODE_LIBRE_RELAY service bit, silently discards
transactions that would be relayed by real Libre Relay nodes, and does not
provide any. Additionally, they have made clear that they intend to ramp up
this sybil attack with the aim of preventing people people from getting
transactions that they disagree with mined:
The costs will increase even more once Libre Relay’s DoS attacks on
bitcoin are countered by enough defensive nodes.
-Chris Guida https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/4
They have also put effort into making the attack more than a simple proof of
concept, e.g. by adding code that attempts to make it more difficult to detect
attacking nodes, by keeping track of transactions received from peers, and then
replying to inv messages with those transactions even when they were
discarded².
With this attack in mind, I thought this would be a good opportunity to review
the math on how effective this type of attack is, as well as some of the
mitigations that could be implement to defeat sybil attacks on transaction
relaying. In particular, I'll present a defense to sybil attacks that is
sufficiently powerful that it may even negate the need for preferential peering
techniques like the NODE_LIBRE_RELAY bit.
Note that I don't deserve credit for any of these ideas. I'm just putting down
in writing some ideas from Gregory Maxwell and others.
# The Effectiveness of Sybil Attacks on Transaction Relaying
Non-listening nodes make a certain number of outgoing, transaction relaying,
connections to listening nodes. In the case of Bitcoin Core, 8 outgoing
transaction relaying nodes; in the case of Libre Relay, an additional 4
outgoing connections to other Libre Relay nodes to relay transactions relevant
to them.
For a sybil attack to succeed against a non-listing node, every one of the N
outgoing connections must be either a sybil attacking node, or a listening node
that itself has been defeated by sybil attack. Additionally, Bitcoin Core makes
outgoing IPv4 and IPv6 connections to a diversity of address space, so the
sybil attacking nodes need to themselves be running on a diverse set of IP
addresses (this is not that difficult to achieve with VPS providers these
days). Thus if the sybil attacking nodes are a ratio of q to all nodes, the
probability of the attack succeeding is q^N.
Against Libre Relay, N=4, this means that the attacker needs to be running ~84%
of all NODE_LIBRE_RELAY advertising nodes to have an attack success probability
of ~50%. Based on information from my Bitcoin seed node, there appear to be
about 15 Libre Relay nodes, so for a 50% attack success probability the
attackers would need to run about 85 attack nodes. If N was increased to 8, the
attackers would need about 172 nodes to achieve the same success rate.
Against *listening* nodes a different type of attack is necessary. The reason
for this is that defenders can easily defeat sybil attacks against listening
nodes by simply connecting to ~all listening nodes at once to ensure that
transaction propagation succeeds. Of course, the attacker can in turn do things
like attempt to exhaust connection slots of Libre Relay nodes, or simply DoS
attack them with packet floods. But those are different types of attack than
the sybil attack we are discussing here.
# Prior Art: Defeating Block Propagation Sybil Attack
Bitcoin Core already includes a defense against sybil attack for block
propagation: the feeler node system. Basically, every ~2 minutes an outgoing
connection is made to a gossiped address to check if a connection can be made;
successful connections are recorded in a table of "tried" addresses. If no new
blocks have been received for 30 minutes, these tried addresses are then used
every 10 minutes to try to find a peer that does know about a new block.
Since this process goes on indefinitely, so long as outgoing connections are
themselves not censored (e.g. by the ISP), the node should eventually find a
non-sybil attacking node and learn about the true most-work chain. Even in
normal operation periods of >30minutes between blocks are fairly common, so
this defense will (eventually) work even if a forked chain exists with some
hash power extending it.
This approach is relatively straightforward for block propagation, as there is
a clear metric: the most-work chain. Peers that aren't giving you the most-work
chain can be ignored, and new peers found. Proof-of-work's inherently
self-validating property means that doing this is cheap and straight forward.
# Directionality
A subtlety to the information censorship sybil attack is there are actually two
different simultaneous attacks: the attack on preventing you from learning
about new information, and the attack on preventing you from distribute new
information to others.
With block propagation, most nodes most directly care about the first class of
attack: they want to learn about the most-work chain, and do not want that
information censored from them.
For miners, in addition to knowing what the most-work chain is, they
(typically³) have a strong incentive to get their new blocks to all nodes as
quickly as possible. Also, all nodes have at least some incentive to do this as
Bitcoin will not function properly if miners are getting censored.
These attacks are not the same! The most-work-chain metric is only directly
detecting and preventing the first class of attack. It only prevents the second
attack indirectly, by making it easier for honest nodes to learn about new
blocks and attempt to themselves propagate that information further.
# Most Fees Metric
For transaction relaying, the moral equivalent to the most-work chain metric
are metrics based on the amount of new transaction fees that peers are
advertising to you. Unfortunately this isn't as straightforward to implement as
the most-work chain metric for a few reasons:
1) Resolution: differences in chain work are very clear, with even a single
additional block being a very significant difference. For transaction relaying,
we'd like to be able to successfully relay transaction types that only add a
small % to total fees.
2) Bandwidth: a chain of 80 byte headers is sufficient to prove most-work;
transactions are much larger.
3) Double-spends: mempools are not a consensus. Your peers may have
transactions that conflict with your transactions, yet in ways that don't
constitute a worthwhile RBF replacement (e.g. two different transactions
with the same fees and fee-rate).
For example, one straight-forward approach would be to simply keep track of a
decaying average of new fees/sec each peer had advertised to you prior to you
advertising the transaction to them. Periodically, you could drop the peer with
the lowest new fees/sec ranking, and then connect to a new peer.
However, it's not clear that this approach has sufficient resolution to
actually detect censorship of relatively uncommon transaction types.
Additionally, since transaction broadcasting is a one-shot event - we don't
have a mempool synchronization mechanism - this approach may not work well if
transaction demand is bursty.
# Most-Fees Next (Dobule) Block Mempool
With the upcoming cluster mempool functionality that is expected to be added to
Core in the near future, transactions will be stored in memory in clusters
ordered by fees: essentially the order in which optimal blocks would be
created. This will make it computationally cheap to determine what the optimal
next block (or blocks) will be by simply iterating through transactions in
order, and stopping when N weight worth of transactions have been found.
Thus nodes can cheaply compute the total fees in the top one or two blocks
worth of transactions they currently have in their mempool, and advertise this
fact to their peers. Finally, to prevent lying, we can add a mechanism for a
peer to get a copy of all these transactions to ensure that they're not missing
out on anything paying enough fees to get mined soon.
While beyond the scope of this summary, there are many set-reconciliation
techniques available to do this in a bandwidth efficient manner. Basically,
through the existing transaction relay mechanisms we can expect mempools to be
relatively consistent between nodes. Thus, to get all transactions that your
peer has for the next block or two that you do not, you just need to transfer
the deltas between their next-block(s) mempool and yours.
Concretely, suppose we do this with the next two blocks worth of transactions.
At worst, each node would need to periodically create a maximum 8MB serialized
"double-block", using up to 8MB of ram. Secondly, to apply this to all outgoing
connections, you'd need to periodically use a set-reconciliation protocol to
download the differences between each of your outgoing peers' double-blocks,
and attempt to add any newly discovered transactions to your mempool. At worst
for 8 peers this would be 64MB of useless data to download, assuming every
single transaction was a conflicting double-spend. Not great. But not that bad.
As with the average fees idea, periodically you would drop the peer advertising
the lowest double-block of fees, and then connect to a new peer to see if
they're better.
Now consider what happens if you are sybil attacked. Due to RBF, with
synchronous mempools across different nodes with the same standardness policies
will have very similar transaction sets; even without active synchronization
long-running mempools across different nodes are already very similar in terms
of total fees. Thus even a small difference in transaction relay policy will
show up as missing transactions. This difference will translate into the sybil
attacking node(s) getting dropped, and honest nodes with policy compatible with
yours eventually being found.
## Peers With More Liberal Relay Policy
If you apply set reconciliation to a peer with a *more* liberal relay policy
than you, they'll have transactions that you will not accept. For example,
imagine the case of a peer that now accepts a new version number.
One way to deal with this could be to just drop peers that give you
transactions that you consider non-standard. So long as reconciliation is only
applied to a subset of all transaction relaying peers, this is fine. Indeed,
even if this is applied to all transaction relaying peers, Bitcoin Core already
connects to additional peers in blocks-only mode. So you'll still get send and
receive blocks and maintain consensus.
## Privacy
Tracking what transactions are in mempools is a potential way for attackers to
trace transactions back to their origin. Provided that set-reconciliation is
only a secondary transaction relay mechanism, with sufficient time delays, this
should not impact privacy as under normal operation transactions will have
already propagated widely making the set reconciliation data non-sensitive.
# Manual Peering With Known-Honest Friendly Nodes
More of a social solution than a technical solution, we should encourage people
to manually peer with other nodes they have a personal relationship with. This
is a powerful technique against sybil attacks for the simple reason that
person-to-person relationships can evaluate honesty in much more powerful ways
than any code could possibly do so.
At the moment, actually doing this is inconvenient. Ideally we would have a
mechanism where node operators could get a simple pubkey@address connection
string from their node to tell to their friends, and equally, import that same
connection string into their bitcoin.conf. This mechanism should use some kind
of node identity to defeat MITM attacks, and also ensure that connection limits
are bypassed for friendly nodes. The existing addnode mechanism doesn't quite
achieve this. Notably, without a node identity mechanism, there's no way for
someone with a static IP address to whitelist a friend's node with a non-static
IP address.
# Footnotes
1) Chris Guida's "garbageman" branch: https://github.com/chrisguida/bitcoin/tree/garbageman,
first presented at the btc++ mempool edition (2025) hackathon
2) https://github.com/chrisguida/bitcoin/commit/e9a921c045d64828a5f0de58d8f2706848c48fd2?s=09
3) https://petertodd.org/2016/block-publication-incentives-for-miners
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Libre Relay nodes by running nodes with their "garbageman" fork¹. This fork
falsely advertise the NODE_LIBRE_RELAY service bit, silently discards
transactions that would be relayed by real Libre Relay nodes, and does not
provide any. Additionally, they have made clear that they intend to ramp up
this sybil attack with the aim of preventing people people from getting
transactions that they disagree with mined:
The costs will increase even more once Libre Relay’s DoS attacks on
bitcoin are countered by enough defensive nodes.
-Chris Guida https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/4
They have also put effort into making the attack more than a simple proof of
concept, e.g. by adding code that attempts to make it more difficult to detect
attacking nodes, by keeping track of transactions received from peers, and then
replying to inv messages with those transactions even when they were
discarded².
With this attack in mind, I thought this would be a good opportunity to review
the math on how effective this type of attack is, as well as some of the
mitigations that could be implement to defeat sybil attacks on transaction
relaying. In particular, I'll present a defense to sybil attacks that is
sufficiently powerful that it may even negate the need for preferential peering
techniques like the NODE_LIBRE_RELAY bit.
Note that I don't deserve credit for any of these ideas. I'm just putting down
in writing some ideas from Gregory Maxwell and others.
# The Effectiveness of Sybil Attacks on Transaction Relaying
Non-listening nodes make a certain number of outgoing, transaction relaying,
connections to listening nodes. In the case of Bitcoin Core, 8 outgoing
transaction relaying nodes; in the case of Libre Relay, an additional 4
outgoing connections to other Libre Relay nodes to relay transactions relevant
to them.
For a sybil attack to succeed against a non-listing node, every one of the N
outgoing connections must be either a sybil attacking node, or a listening node
that itself has been defeated by sybil attack. Additionally, Bitcoin Core makes
outgoing IPv4 and IPv6 connections to a diversity of address space, so the
sybil attacking nodes need to themselves be running on a diverse set of IP
addresses (this is not that difficult to achieve with VPS providers these
days). Thus if the sybil attacking nodes are a ratio of q to all nodes, the
probability of the attack succeeding is q^N.
Against Libre Relay, N=4, this means that the attacker needs to be running ~84%
of all NODE_LIBRE_RELAY advertising nodes to have an attack success probability
of ~50%. Based on information from my Bitcoin seed node, there appear to be
about 15 Libre Relay nodes, so for a 50% attack success probability the
attackers would need to run about 85 attack nodes. If N was increased to 8, the
attackers would need about 172 nodes to achieve the same success rate.
Against *listening* nodes a different type of attack is necessary. The reason
for this is that defenders can easily defeat sybil attacks against listening
nodes by simply connecting to ~all listening nodes at once to ensure that
transaction propagation succeeds. Of course, the attacker can in turn do things
like attempt to exhaust connection slots of Libre Relay nodes, or simply DoS
attack them with packet floods. But those are different types of attack than
the sybil attack we are discussing here.
# Prior Art: Defeating Block Propagation Sybil Attack
Bitcoin Core already includes a defense against sybil attack for block
propagation: the feeler node system. Basically, every ~2 minutes an outgoing
connection is made to a gossiped address to check if a connection can be made;
successful connections are recorded in a table of "tried" addresses. If no new
blocks have been received for 30 minutes, these tried addresses are then used
every 10 minutes to try to find a peer that does know about a new block.
Since this process goes on indefinitely, so long as outgoing connections are
themselves not censored (e.g. by the ISP), the node should eventually find a
non-sybil attacking node and learn about the true most-work chain. Even in
normal operation periods of >30minutes between blocks are fairly common, so
this defense will (eventually) work even if a forked chain exists with some
hash power extending it.
This approach is relatively straightforward for block propagation, as there is
a clear metric: the most-work chain. Peers that aren't giving you the most-work
chain can be ignored, and new peers found. Proof-of-work's inherently
self-validating property means that doing this is cheap and straight forward.
# Directionality
A subtlety to the information censorship sybil attack is there are actually two
different simultaneous attacks: the attack on preventing you from learning
about new information, and the attack on preventing you from distribute new
information to others.
With block propagation, most nodes most directly care about the first class of
attack: they want to learn about the most-work chain, and do not want that
information censored from them.
For miners, in addition to knowing what the most-work chain is, they
(typically³) have a strong incentive to get their new blocks to all nodes as
quickly as possible. Also, all nodes have at least some incentive to do this as
Bitcoin will not function properly if miners are getting censored.
These attacks are not the same! The most-work-chain metric is only directly
detecting and preventing the first class of attack. It only prevents the second
attack indirectly, by making it easier for honest nodes to learn about new
blocks and attempt to themselves propagate that information further.
# Most Fees Metric
For transaction relaying, the moral equivalent to the most-work chain metric
are metrics based on the amount of new transaction fees that peers are
advertising to you. Unfortunately this isn't as straightforward to implement as
the most-work chain metric for a few reasons:
1) Resolution: differences in chain work are very clear, with even a single
additional block being a very significant difference. For transaction relaying,
we'd like to be able to successfully relay transaction types that only add a
small % to total fees.
2) Bandwidth: a chain of 80 byte headers is sufficient to prove most-work;
transactions are much larger.
3) Double-spends: mempools are not a consensus. Your peers may have
transactions that conflict with your transactions, yet in ways that don't
constitute a worthwhile RBF replacement (e.g. two different transactions
with the same fees and fee-rate).
For example, one straight-forward approach would be to simply keep track of a
decaying average of new fees/sec each peer had advertised to you prior to you
advertising the transaction to them. Periodically, you could drop the peer with
the lowest new fees/sec ranking, and then connect to a new peer.
However, it's not clear that this approach has sufficient resolution to
actually detect censorship of relatively uncommon transaction types.
Additionally, since transaction broadcasting is a one-shot event - we don't
have a mempool synchronization mechanism - this approach may not work well if
transaction demand is bursty.
# Most-Fees Next (Dobule) Block Mempool
With the upcoming cluster mempool functionality that is expected to be added to
Core in the near future, transactions will be stored in memory in clusters
ordered by fees: essentially the order in which optimal blocks would be
created. This will make it computationally cheap to determine what the optimal
next block (or blocks) will be by simply iterating through transactions in
order, and stopping when N weight worth of transactions have been found.
Thus nodes can cheaply compute the total fees in the top one or two blocks
worth of transactions they currently have in their mempool, and advertise this
fact to their peers. Finally, to prevent lying, we can add a mechanism for a
peer to get a copy of all these transactions to ensure that they're not missing
out on anything paying enough fees to get mined soon.
While beyond the scope of this summary, there are many set-reconciliation
techniques available to do this in a bandwidth efficient manner. Basically,
through the existing transaction relay mechanisms we can expect mempools to be
relatively consistent between nodes. Thus, to get all transactions that your
peer has for the next block or two that you do not, you just need to transfer
the deltas between their next-block(s) mempool and yours.
Concretely, suppose we do this with the next two blocks worth of transactions.
At worst, each node would need to periodically create a maximum 8MB serialized
"double-block", using up to 8MB of ram. Secondly, to apply this to all outgoing
connections, you'd need to periodically use a set-reconciliation protocol to
download the differences between each of your outgoing peers' double-blocks,
and attempt to add any newly discovered transactions to your mempool. At worst
for 8 peers this would be 64MB of useless data to download, assuming every
single transaction was a conflicting double-spend. Not great. But not that bad.
As with the average fees idea, periodically you would drop the peer advertising
the lowest double-block of fees, and then connect to a new peer to see if
they're better.
Now consider what happens if you are sybil attacked. Due to RBF, with
synchronous mempools across different nodes with the same standardness policies
will have very similar transaction sets; even without active synchronization
long-running mempools across different nodes are already very similar in terms
of total fees. Thus even a small difference in transaction relay policy will
show up as missing transactions. This difference will translate into the sybil
attacking node(s) getting dropped, and honest nodes with policy compatible with
yours eventually being found.
## Peers With More Liberal Relay Policy
If you apply set reconciliation to a peer with a *more* liberal relay policy
than you, they'll have transactions that you will not accept. For example,
imagine the case of a peer that now accepts a new version number.
One way to deal with this could be to just drop peers that give you
transactions that you consider non-standard. So long as reconciliation is only
applied to a subset of all transaction relaying peers, this is fine. Indeed,
even if this is applied to all transaction relaying peers, Bitcoin Core already
connects to additional peers in blocks-only mode. So you'll still get send and
receive blocks and maintain consensus.
## Privacy
Tracking what transactions are in mempools is a potential way for attackers to
trace transactions back to their origin. Provided that set-reconciliation is
only a secondary transaction relay mechanism, with sufficient time delays, this
should not impact privacy as under normal operation transactions will have
already propagated widely making the set reconciliation data non-sensitive.
# Manual Peering With Known-Honest Friendly Nodes
More of a social solution than a technical solution, we should encourage people
to manually peer with other nodes they have a personal relationship with. This
is a powerful technique against sybil attacks for the simple reason that
person-to-person relationships can evaluate honesty in much more powerful ways
than any code could possibly do so.
At the moment, actually doing this is inconvenient. Ideally we would have a
mechanism where node operators could get a simple pubkey@address connection
string from their node to tell to their friends, and equally, import that same
connection string into their bitcoin.conf. This mechanism should use some kind
of node identity to defeat MITM attacks, and also ensure that connection limits
are bypassed for friendly nodes. The existing addnode mechanism doesn't quite
achieve this. Notably, without a node identity mechanism, there's no way for
someone with a static IP address to whitelist a friend's node with a non-static
IP address.
# Footnotes
1) Chris Guida's "garbageman" branch: https://github.com/chrisguida/bitcoin/tree/garbageman,
first presented at the btc++ mempool edition (2025) hackathon
2) https://github.com/chrisguida/bitcoin/commit/e9a921c045d64828a5f0de58d8f2706848c48fd2?s=09
3) https://petertodd.org/2016/block-publication-incentives-for-miners
--
https://petertodd.org 'peter'[:-1]@petertodd.org
John Carvalho
May 27, 2025, 7:42:22 AMMay 27
to Peter Todd, bitco...@googlegroups.com
I noticed your mention of a missing pubkey identity capability.
A censorship-resistant key-based discovery mechanism is available, PKDNS, at github.com/pubky/pkarr (also /mainline and /pkdns), which essentially provides public-key domains controlled by the keyholder.
No blockchains, just the largest, oldest, p2p network on earth, Mainline DHT.
This could be used to dynamically provide or update any endpoint, associate or disassociate keys, or create revokable account-based sessions, etc.
These links may address peoples' likely counterarguments:
Maybe this helps you, or others looking for such primitives!
--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40petertodd.org.
Chris Guida
Jun 2, 2025, 11:34:20 PMJun 2
to John Carvalho, Peter Todd, bitco...@googlegroups.com
Good morning, list!
That seems like a good analysis, Peter, thanks for writing that up.
The following is an explanation of why I decided to create Garbageman. Apologies for its length. I tried to make it shorter, but I felt like I needed a lot of space to catch everyone up to the pro-filtering (pro-rate-limiting) position, which I’ve not seen represented much on this list. Please reach out to me if you need something clarified or if I got anything wrong. I am constantly revising my position based on new information, so please do not interpret it as carved in stone.
Also, please let me know if this list is not the proper venue for this discussion. It gets kind of philosophical.
For those who don't know, I made Garbageman as a hackathon project to demonstrate that the battle against spam is not hopeless.
The project's mission of stopping Libre Relay's spread of garbage around the bitcoin network has proven very popular among noderunners, so I decided to continue developing it in order to meet this demand.
As I've discussed the spam issue with many, many people over the last couple of years, I've noticed that those in the anti-filter camp often use LR as a rhetorical device, effectively arguing "there's no way to stop this". Well, Garbageman is an assertion to the contrary. I think the battle should be fought, and that we should see how it plays out, because I think we can win. For me, winning means keeping bitcoin both spam-resistant and censorship-resistant.
Almost no one I've ever talked to likes the spam, even those in the anti-filter camp. Likewise, almost no one I know who runs a node wants to relay non-monetary transactions. But bitcoiners are feeling demoralized after the BRC-20 attack of 2023-24, which expanded the utxoset from 5GB to 12GB [0], significantly raising the minimum cost of a bitcoin node, while core maintainers refused to accept PRs that would have mitigated the spam. So I hope that Garbageman can be a demonstration that all is not lost, and that noderunners who wish to shoulder some responsibility can make a big enough impact to deter spammers, if we all work together.
Peter's OP, while containing a lot of useful analysis, also contains some inaccuracies I would like to correct.
While Peter characterizes Garbageman as an "attack" - and he is correct that it is an attack on Libre Relay - what he leaves out is that Libre Relay itself is an attack on bitcoin, and thus Garbageman is a defensive measure from the point of view of the bitcoin network.
Specifically, Libre Relay facilitates denial-of-service attacks on bitcoin, because it assists Ponzi promoters in launching their Ponzis using metaprotocols directly on bitcoin, which, as we've seen with past waves of spam, can easily overwhelm block space, sending fees sky-high for months on end. This of course crowds out real monetary usages, such as merchants in developing countries trying to start self-custodial Lightning points-of-sale. It also tends to encourage utxoset bloat (even if the arbitrary data itself is not stored in the utxoset, as we saw with BRC-20's ~tripling of utxoset data [0] using the inscriptions hack to stuff data into the witness).
That is to say: Libre Relay intentionally increases the likelihood that people will not be able to use bitcoin as money. Permissionless money is, of course, the primary service that bitcoin offers, and its entire reason for existence. So when Libre Relay facilitates the mining of transactions associated with altcoin Ponzis on bitcoin, it is actively complicit in perpetrating denial-of-service attacks against bitcoin.
LR operates by using the peer relay network in an unintended way. It attempts to circumvent filters active on honest nodes by preferentially peering with other LR nodes. Garbageman subverts this mechanism by signaling on the same bit that LR nodes use to identify other LR nodes, then throwing away any garbage that comes its way. Assuming that noderunners who don't like spam vastly outnumber those who do (very likely in my experience), it should be fairly straightforward to protect bitcoin against LR's abuse by using up the preferential connections on LR nodes, preventing them from finding each other.
"NODE_LIBRE_RELAY" is not defined anywhere in bitcoin core or any other official documentation. Bit 29 is just a random bit reserved for future use, as far as the bitcoin protocol itself is concerned. So when Peter says Garbageman "falsely advertises the NODE_LIBRE_RELAY service bit", this is incorrect. It is not possible for GM or any other software to misuse this bit, as it has no official significance.
Peter also claims that the Garbageman noderunner community's goal is to "[prevent] people from getting transactions that they disagree with mined". This is also false. In this claim, as filter opponents often do, Peter is conflating spam filtration with censorship. They are, however, complete opposite ends of a spectrum.
Censorship is the complete or near-complete prohibition of transactions for subjective reasons, usually according to some kind of "blacklist" like OFAC. Such behavior is obviously extremely harmful to bitcoin, as one of its core properties is censorship resistance (aka permissionlessness). Luckily, censorship on bitcoin is extremely unlikely, given that just one block template creator with a small percentage of total hashrate can mine whatever transactions it wants. As opponents of filtering love to point out, the miner can even solicit such transactions out-of-band, avoiding mempool filters entirely. They almost never realize that they are merely bolstering the view that bitcoin is hard to censor, and not that it is hard to deter spam on bitcoin.
Spam filtration, conversely, is a rate-limiting of transactions based on objective criteria, which serves to deter, but not completely block, the creation and confirmation of abusive transactions into the chain. Spam filtration, in contrast to censorship, is harmless, and in fact absolutely essential to bitcoin's survival. Why? Because bitcoin's purpose as money is impossible to codify into the consensus rules. Even if we activated some kind of hashing or signing scheme to prevent arbitrary data by consensus (such as the one from Greg Maxwell that Peter brought up in an earlier thread [1]), such a change would still not fully prohibit the abuse of key grinding, etc, for storing arbitrary data (though it would increase costs substantially).
What this means is that bitcoin's identity as money is only enforceable at the social and mempool policy layers. So when core devs enumerate the "three reasons" [2] mempool policy exists, they are missing reason 4:
4) Making sure bitcoin stays money
A blockchain's technology is tightly intertwined with its culture. We've seen historical examples of how tech influences culture, and vice versa. Some examples:
- In BSV, the blocks are so huge and the transaction set so unwieldy, that everyone thinks it's absurd for individuals to run nodes (because it is).
- In Ethereum:
The list goes on and on. The point is that, if we still want bitcoin to be money in a few years, we need to fight to make sure that monetary transactions dominate, and that other use cases do not get the upper hand. If making payments with bitcoin becomes too difficult, then the culture will simply stop valuing payments.
We've already seen a concerning shift in this direction over the last decade as the Lightning Network has been getting built out. During that time, bitcoin’s culture has shifted such that statements from prominent figures unironically discourage spending bitcoin at merchants that directly accept it. Getting Lightning to where it is today took 4 soft forks, a fork war, and a decade of hard work from some of our best devs. Now that Lightning works, we should go all-in on making sure merchants are adopting it, instead of letting non-monetary use cases drown it out.
The anti-filter side seems to think that other use cases cannot drown out the monetary use case, because of transaction fees. In order to believe that fees are sufficient to make sure bitcoin stays money, you'd have to assume that cloud storage with ironclad censorship resistance, immutability, and availability guarantees, for any arbitrary data, for a single upfront fee, for the rest of eternity, would have less demand than Lightning channel opens and closes. This claim seems terribly dubious to me, as it’s already been proven that Ponzi gamblers are willing to dump millions of dollars into fees in order to store their garbage. And we haven’t even cracked the surface of all possible non-monetary “use cases”, because bitcoin’s maintainers have historically been hostile to these uses, so the vast majority of their would-be creators have simply not even considered bitcoin an option.
Currently, however, core devs are very fond of "incentive compatibility" (or "consensus maximalism"). As far as I understand it, this means making mempool policy as close as possible to the consensus rules, so that miners can maximize their short-term profits. While this is a good thing to design for generally because it makes bitcoin much more predictable, it becomes harmful when taken to its logical extreme. Since bitcoin's identity as money cannot be enforced at the consensus layer, and since non-monetary use cases have orders of magnitude more economic demand than monetary ones, incentive compatibility, when maximized above all other concerns, means stuffing bitcoin with as much meaningless garbage as possible. This implies that incentive compatibility is ultimately incompatible with bitcoin remaining money.
Sensible mempool filters are thus the single most powerful tool in our arsenal for giving Lightning a fighting chance and making sure bitcoin stays money for the long term. In addition to sending a strong social signal as to what noderunners prefer, they also allow the relay network to raise costs on spammers, while giving a free ride to actual payments, which are the whole reason the relay network exists. They are the only way I know of for bitcoin’s social layer to exert direct economic pressure on spammers.
Yes, there are most likely slight centralization pressures that can result from large miners soliciting high-fee spam out-of-band, but if enough noderunners are filtering abusive transactions, miners confirming large amounts of these transactions can be seen as hostile, and hostile mining pools have historically yielded to sufficient social pressure, because for a mining pool, social pressure often translates, directly or indirectly, to economic pressure.
If mining pools persist in mining blocks filled with garbage, that will be a sign that we need to break up the mining pools (by encouraging their hashers to boycott them), or, in extreme cases, to fire the miners by changing the PoW algorithm. It would seem that sensible mining pool operators would stop misbehaving well before this point, to avoid undermining their (presumably large) investment.
Fortunately, if the community of noderunners comes together and decides on sensible defaults, the mining pools have historically heeded its decisions. Prior to mempoolfullrbf, it was rare to see mining pools flouting the will of the noderunners. This is because the core maintainers always listened to the noderunners when deciding on the default mempool policy. However, for some reason, in the case of mempoolfullrbf, core devs decided to keep it defaulted to “off”, even though the vast majority of noderunners felt that it was a sensible thing to turn on. I worked at a company that provides turnkey bitcoin nodes during that episode, and we even exposed mempoolfullrbf as a config option because users wanted to be allowed to turn it on.
Peter himself, using Libre Relay, was ultimately responsible for getting this option defaulted to “on” in core, by taking the battle directly to the mining pools. What the anti-filter crowd does not seem to realize is that Peter never would have succeeded if the noderunner community had been opposing him on this. Practically everyone agreed that fullrbf was long past due, except a handful of people who didn’t understand that zeroconf is fundamentally insecure, and that Lightning is way better if you don’t want to wait for a confirmation.
Peter should be commended for finally getting fullrbf active on mainnet. But Libre Relay has now outlived its utility. LR has now been converted into a tool for strong-arming core into removing all its filters, and shoving garbage down everyone’s throats. Though noderunners were happy to go along with LR when it was just about getting fullrbf activated, we are overwhelmingly opposed to raising datacarrier limits. Garbageman is the manifestation of that opposition.
Garbageman protects the bitcoin network by facilitating spam filtration, an essential function for bitcoin, while avoiding censorship. So Peter's chosen subject line, "Censorship Resistant Transaction Relay", is misleading. What he really means is "Spam-Filtration-Resistant Transaction Relay" which, of course, is not desirable at all.
Yes, I’m sure there are strategies for getting LR nodes to detect GM nodes and banning them. And I’m equally sure that, if implemented:
1) Very few people will run them. Only LR nodes are likely to run the garbage-maximizing strategies Peter outlined above. I don’t know of any noderunners in their right minds who would run them.
2) The pro-spam-filtration noderunner community will work around these detection methods any way we can, and we will never give up.
Libre Relay is a direct threat to bitcoin’s ability to remain money, and the threat must be countered.
Garbageman restores the balance.
Best regards,
--Chris Guida
[0]: https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=10m&viewPanel=8&from=1588309200000&to=now
[1]: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/QwkPB2HtEQAJ
[2]: https://gist.github.com/instagibbs/c436110890ab25aa9997b13c2270d5ce#why-standardness-policy-exists
That seems like a good analysis, Peter, thanks for writing that up.
The following is an explanation of why I decided to create Garbageman. Apologies for its length. I tried to make it shorter, but I felt like I needed a lot of space to catch everyone up to the pro-filtering (pro-rate-limiting) position, which I’ve not seen represented much on this list. Please reach out to me if you need something clarified or if I got anything wrong. I am constantly revising my position based on new information, so please do not interpret it as carved in stone.
Also, please let me know if this list is not the proper venue for this discussion. It gets kind of philosophical.
For those who don't know, I made Garbageman as a hackathon project to demonstrate that the battle against spam is not hopeless.
The project's mission of stopping Libre Relay's spread of garbage around the bitcoin network has proven very popular among noderunners, so I decided to continue developing it in order to meet this demand.
As I've discussed the spam issue with many, many people over the last couple of years, I've noticed that those in the anti-filter camp often use LR as a rhetorical device, effectively arguing "there's no way to stop this". Well, Garbageman is an assertion to the contrary. I think the battle should be fought, and that we should see how it plays out, because I think we can win. For me, winning means keeping bitcoin both spam-resistant and censorship-resistant.
Almost no one I've ever talked to likes the spam, even those in the anti-filter camp. Likewise, almost no one I know who runs a node wants to relay non-monetary transactions. But bitcoiners are feeling demoralized after the BRC-20 attack of 2023-24, which expanded the utxoset from 5GB to 12GB [0], significantly raising the minimum cost of a bitcoin node, while core maintainers refused to accept PRs that would have mitigated the spam. So I hope that Garbageman can be a demonstration that all is not lost, and that noderunners who wish to shoulder some responsibility can make a big enough impact to deter spammers, if we all work together.
Peter's OP, while containing a lot of useful analysis, also contains some inaccuracies I would like to correct.
While Peter characterizes Garbageman as an "attack" - and he is correct that it is an attack on Libre Relay - what he leaves out is that Libre Relay itself is an attack on bitcoin, and thus Garbageman is a defensive measure from the point of view of the bitcoin network.
Specifically, Libre Relay facilitates denial-of-service attacks on bitcoin, because it assists Ponzi promoters in launching their Ponzis using metaprotocols directly on bitcoin, which, as we've seen with past waves of spam, can easily overwhelm block space, sending fees sky-high for months on end. This of course crowds out real monetary usages, such as merchants in developing countries trying to start self-custodial Lightning points-of-sale. It also tends to encourage utxoset bloat (even if the arbitrary data itself is not stored in the utxoset, as we saw with BRC-20's ~tripling of utxoset data [0] using the inscriptions hack to stuff data into the witness).
That is to say: Libre Relay intentionally increases the likelihood that people will not be able to use bitcoin as money. Permissionless money is, of course, the primary service that bitcoin offers, and its entire reason for existence. So when Libre Relay facilitates the mining of transactions associated with altcoin Ponzis on bitcoin, it is actively complicit in perpetrating denial-of-service attacks against bitcoin.
LR operates by using the peer relay network in an unintended way. It attempts to circumvent filters active on honest nodes by preferentially peering with other LR nodes. Garbageman subverts this mechanism by signaling on the same bit that LR nodes use to identify other LR nodes, then throwing away any garbage that comes its way. Assuming that noderunners who don't like spam vastly outnumber those who do (very likely in my experience), it should be fairly straightforward to protect bitcoin against LR's abuse by using up the preferential connections on LR nodes, preventing them from finding each other.
"NODE_LIBRE_RELAY" is not defined anywhere in bitcoin core or any other official documentation. Bit 29 is just a random bit reserved for future use, as far as the bitcoin protocol itself is concerned. So when Peter says Garbageman "falsely advertises the NODE_LIBRE_RELAY service bit", this is incorrect. It is not possible for GM or any other software to misuse this bit, as it has no official significance.
Peter also claims that the Garbageman noderunner community's goal is to "[prevent] people from getting transactions that they disagree with mined". This is also false. In this claim, as filter opponents often do, Peter is conflating spam filtration with censorship. They are, however, complete opposite ends of a spectrum.
Censorship is the complete or near-complete prohibition of transactions for subjective reasons, usually according to some kind of "blacklist" like OFAC. Such behavior is obviously extremely harmful to bitcoin, as one of its core properties is censorship resistance (aka permissionlessness). Luckily, censorship on bitcoin is extremely unlikely, given that just one block template creator with a small percentage of total hashrate can mine whatever transactions it wants. As opponents of filtering love to point out, the miner can even solicit such transactions out-of-band, avoiding mempool filters entirely. They almost never realize that they are merely bolstering the view that bitcoin is hard to censor, and not that it is hard to deter spam on bitcoin.
Spam filtration, conversely, is a rate-limiting of transactions based on objective criteria, which serves to deter, but not completely block, the creation and confirmation of abusive transactions into the chain. Spam filtration, in contrast to censorship, is harmless, and in fact absolutely essential to bitcoin's survival. Why? Because bitcoin's purpose as money is impossible to codify into the consensus rules. Even if we activated some kind of hashing or signing scheme to prevent arbitrary data by consensus (such as the one from Greg Maxwell that Peter brought up in an earlier thread [1]), such a change would still not fully prohibit the abuse of key grinding, etc, for storing arbitrary data (though it would increase costs substantially).
What this means is that bitcoin's identity as money is only enforceable at the social and mempool policy layers. So when core devs enumerate the "three reasons" [2] mempool policy exists, they are missing reason 4:
4) Making sure bitcoin stays money
Spam filtration is thus a vital component to bitcoin's success, if its goal is to be the best money ever.
Yes, consensus is king, but if we deny the importance of the social and mempool policy layers in maintaining bitcoin's identity as money, then bitcoin will inevitably cease to be money and become corrupted into something resembling Ethereum; that is: a giant dumpster fire of nobody-knows-what.
So when Libre Relay undermines spam filtration, it
is not only facilitating DoS attacks on bitcoin; it is contributing to a
situation in which the DoS becomes permanent, because bitcoin is no longer money at all.
A blockchain's technology is tightly intertwined with its culture. We've seen historical examples of how tech influences culture, and vice versa. Some examples:
- In BSV, the blocks are so huge and the transaction set so unwieldy, that everyone thinks it's absurd for individuals to run nodes (because it is).
- In Ethereum:
- The blockchain is large and complex - so individuals generally think running full nodes is unimportant - so very few people run full nodes - so the devs are not concerned with making it easier for people to run full nodes.
- The leadership has no principles and no particular vision for what the blockchain is trying to achieve - so short-term incentives dominate.
- The contracting language is very challenging to secure - so making useful contracts that actually work is deprioritized - so 99.99% of the activity is dedicated to scamming.
- In Monero, the supply is difficult to audit - so everyone thinks that auditing the supply is unimportant.- The leadership has no principles and no particular vision for what the blockchain is trying to achieve - so short-term incentives dominate.
- The contracting language is very challenging to secure - so making useful contracts that actually work is deprioritized - so 99.99% of the activity is dedicated to scamming.
The list goes on and on. The point is that, if we still want bitcoin to be money in a few years, we need to fight to make sure that monetary transactions dominate, and that other use cases do not get the upper hand. If making payments with bitcoin becomes too difficult, then the culture will simply stop valuing payments.
We've already seen a concerning shift in this direction over the last decade as the Lightning Network has been getting built out. During that time, bitcoin’s culture has shifted such that statements from prominent figures unironically discourage spending bitcoin at merchants that directly accept it. Getting Lightning to where it is today took 4 soft forks, a fork war, and a decade of hard work from some of our best devs. Now that Lightning works, we should go all-in on making sure merchants are adopting it, instead of letting non-monetary use cases drown it out.
The anti-filter side seems to think that other use cases cannot drown out the monetary use case, because of transaction fees. In order to believe that fees are sufficient to make sure bitcoin stays money, you'd have to assume that cloud storage with ironclad censorship resistance, immutability, and availability guarantees, for any arbitrary data, for a single upfront fee, for the rest of eternity, would have less demand than Lightning channel opens and closes. This claim seems terribly dubious to me, as it’s already been proven that Ponzi gamblers are willing to dump millions of dollars into fees in order to store their garbage. And we haven’t even cracked the surface of all possible non-monetary “use cases”, because bitcoin’s maintainers have historically been hostile to these uses, so the vast majority of their would-be creators have simply not even considered bitcoin an option.
Currently, however, core devs are very fond of "incentive compatibility" (or "consensus maximalism"). As far as I understand it, this means making mempool policy as close as possible to the consensus rules, so that miners can maximize their short-term profits. While this is a good thing to design for generally because it makes bitcoin much more predictable, it becomes harmful when taken to its logical extreme. Since bitcoin's identity as money cannot be enforced at the consensus layer, and since non-monetary use cases have orders of magnitude more economic demand than monetary ones, incentive compatibility, when maximized above all other concerns, means stuffing bitcoin with as much meaningless garbage as possible. This implies that incentive compatibility is ultimately incompatible with bitcoin remaining money.
Sensible mempool filters are thus the single most powerful tool in our arsenal for giving Lightning a fighting chance and making sure bitcoin stays money for the long term. In addition to sending a strong social signal as to what noderunners prefer, they also allow the relay network to raise costs on spammers, while giving a free ride to actual payments, which are the whole reason the relay network exists. They are the only way I know of for bitcoin’s social layer to exert direct economic pressure on spammers.
Yes, there are most likely slight centralization pressures that can result from large miners soliciting high-fee spam out-of-band, but if enough noderunners are filtering abusive transactions, miners confirming large amounts of these transactions can be seen as hostile, and hostile mining pools have historically yielded to sufficient social pressure, because for a mining pool, social pressure often translates, directly or indirectly, to economic pressure.
If mining pools persist in mining blocks filled with garbage, that will be a sign that we need to break up the mining pools (by encouraging their hashers to boycott them), or, in extreme cases, to fire the miners by changing the PoW algorithm. It would seem that sensible mining pool operators would stop misbehaving well before this point, to avoid undermining their (presumably large) investment.
Fortunately, if the community of noderunners comes together and decides on sensible defaults, the mining pools have historically heeded its decisions. Prior to mempoolfullrbf, it was rare to see mining pools flouting the will of the noderunners. This is because the core maintainers always listened to the noderunners when deciding on the default mempool policy. However, for some reason, in the case of mempoolfullrbf, core devs decided to keep it defaulted to “off”, even though the vast majority of noderunners felt that it was a sensible thing to turn on. I worked at a company that provides turnkey bitcoin nodes during that episode, and we even exposed mempoolfullrbf as a config option because users wanted to be allowed to turn it on.
Peter himself, using Libre Relay, was ultimately responsible for getting this option defaulted to “on” in core, by taking the battle directly to the mining pools. What the anti-filter crowd does not seem to realize is that Peter never would have succeeded if the noderunner community had been opposing him on this. Practically everyone agreed that fullrbf was long past due, except a handful of people who didn’t understand that zeroconf is fundamentally insecure, and that Lightning is way better if you don’t want to wait for a confirmation.
Peter should be commended for finally getting fullrbf active on mainnet. But Libre Relay has now outlived its utility. LR has now been converted into a tool for strong-arming core into removing all its filters, and shoving garbage down everyone’s throats. Though noderunners were happy to go along with LR when it was just about getting fullrbf activated, we are overwhelmingly opposed to raising datacarrier limits. Garbageman is the manifestation of that opposition.
Garbageman protects the bitcoin network by facilitating spam filtration, an essential function for bitcoin, while avoiding censorship. So Peter's chosen subject line, "Censorship Resistant Transaction Relay", is misleading. What he really means is "Spam-Filtration-Resistant Transaction Relay" which, of course, is not desirable at all.
Yes, I’m sure there are strategies for getting LR nodes to detect GM nodes and banning them. And I’m equally sure that, if implemented:
1) Very few people will run them. Only LR nodes are likely to run the garbage-maximizing strategies Peter outlined above. I don’t know of any noderunners in their right minds who would run them.
2) The pro-spam-filtration noderunner community will work around these detection methods any way we can, and we will never give up.
Libre Relay is a direct threat to bitcoin’s ability to remain money, and the threat must be countered.
Garbageman restores the balance.
Best regards,
--Chris Guida
[0]: https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=10m&viewPanel=8&from=1588309200000&to=now
[1]: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/QwkPB2HtEQAJ
[2]: https://gist.github.com/instagibbs/c436110890ab25aa9997b13c2270d5ce#why-standardness-policy-exists
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com.
Sjors Provoost
Jun 3, 2025, 4:00:44 AMJun 3
to bitco...@googlegroups.com
Op 3 jun 2025, om 04:52 heeft Chris Guida <chris...@gmail.com> het volgende geschreven:
Also, please let me know if this list is not the proper venue for this discussion. It gets kind of philosophical.
More importantly it doesn't contain any numerical analysis as to its effectiveness.
Spam filtration, conversely, is a rate-limiting of transactions based on objective criteria,
Presence on the OFAC list is an objective criterion. Your distinction between "objective" and "subjective" seems rather arbitrary. In any case it's not relevant for the purpose of censorship resistance.
The reality is that there are different groups using Bitcoin and they have different opinions on which transactions it should include.
Governments are one such group and they could decide tomorrow to spin up a bigger version Garbageman and disrupt the entire mempool. If they perceive it as an attack on their interest. As a result everyone has to submit transactions directly to a handful of, often US based, pools.
If we're going down the route of openly innovating attacks against the mempool, we should also continue innovating countermeasures, as Peter Todd did.
Garbageman restores the balance.
This is extremely vague and avoids the question of effectiveness.
What percentage of attempted "spam" transactions are prevented from entering a block? What's the average delay in seconds?
You speak of "rate limiting", but delaying propagation doesn't rate limit anything. Unless you completely block some percentage of transactions, the same amount of spam ends up in blocks, just a little bit later. The rate, e.g. gigabytes per months, stays the same.
Peter's original email also doesn't answer this: presumably because he's trying to be generous:
For a sybil attack to succeed against a non-listing node, every one of the N
outgoing connections must be either a sybil attacking node, or a listening node
that itself has been defeated by sybil attack.
"succeed" here just means the transaction doesn't reach a miner in the initial broadcast attempt.
If the "spammers" use extremely naive software, perhaps they never try again and the sybil attack was successful. But this assumes an adversary who doesn't adapt, which is not a reasonable assumption.
Anyone would understand from their own experience if that if a transaction doesn't go through, you try again. You don't just accept that you've been rate limited.
The simplest next move would be for their software to just connect to more Libre relay peers and broadcast the transaction again.
Or people can just spin up more Libre Relay nodes. Both miners and issuers of various scam tokens have a monetary incentive to do that. Whereas proponents of filters are (so far) not willing to invest serious money. E.g. when I challenged Luke Dashjr in an earlier post to reorg a single block with spam, he didn't respond [1]. Worse, Ocean proactively offers "Core" [0] templates. Although running a node is cheap, if this becomes an arms race, the side that actually spends money has the advantage.
But let's say, after all this you find a way to make Garbageman effective, that it actually causes and sustains an economically meaningful delay between when a transaction is submitted to Libre Relay network and when its included in a block. 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.
- Sjors
Greg Maxwell
Jun 3, 2025, 2:29:12 PMJun 3
to Sjors Provoost, bitco...@googlegroups.com
On Tue, Jun 3, 2025 at 8:00 AM Sjors Provoost <sj...@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.
Peter Todd
Jun 3, 2025, 2:29:36 PMJun 3
to Sjors Provoost, bitco...@googlegroups.com
On Tue, Jun 03, 2025 at 08:50:34AM +0200, Sjors Provoost wrote:
> Or people can just spin up more Libre Relay nodes. Both miners and issuers of various scam tokens have a monetary incentive to do that. Whereas proponents of filters are (so far) not willing to invest serious money. E.g. when I challenged Luke Dashjr in an earlier post to reorg a single block with spam, he didn't respond [1]. Worse, Ocean proactively offers "Core" [0] templates. Although running a node is cheap, if this becomes an arms race, the side that actually spends money has the advantage.
I need to point out that you're being unfair to Ocean here: with their <1% hash
> Or people can just spin up more Libre Relay nodes. Both miners and issuers of various scam tokens have a monetary incentive to do that. Whereas proponents of filters are (so far) not willing to invest serious money. E.g. when I challenged Luke Dashjr in an earlier post to reorg a single block with spam, he didn't respond [1]. Worse, Ocean proactively offers "Core" [0] templates. Although running a node is cheap, if this becomes an arms race, the side that actually spends money has the advantage.
power it's damn near impossible for them to reorg blocks. The reason is because
if there are two blocks at the same height, Bitcoin Core accepts the first
block seen.
Thus if Ocean wants to reorg a "spam" block out, they need to find not just
one, but two blocks in a row before any other miner finds one. The probability
of that happening is (very) roughly 1% * 1% = 0.01% per attempt. Given that
blocks are worth ~$300k these days, you're asking them to spend tens of
millions of dollars worth of hash power just to reorg out a single block.
It's not going to happen.
Sjors Provoost
Jun 3, 2025, 2:30:16 PMJun 3
to Peter Todd, bitco...@googlegroups.com
They can broadcast an expensive signal, i.e. make a statement, with a single block even if nobody builds on it.
More cheaply, and perhaps more effective, they could publish a feed of weak blocks on their social media, containing the hash of each rejected block in a coinbase OP_RETURN. They could mine this block for just a few seconds or minutes, before resuming to mine on the tip.
Even a low success rate could serve as a deterrent to other miners against including "bad" transactions. Rationally the attack would have to cost about as much as the extra revenue from censored fees, but risk aversion would probably leverage to this strategy.
Of course I'd rather not go down this path.
- Sjors
More cheaply, and perhaps more effective, they could publish a feed of weak blocks on their social media, containing the hash of each rejected block in a coinbase OP_RETURN. They could mine this block for just a few seconds or minutes, before resuming to mine on the tip.
Even a low success rate could serve as a deterrent to other miners against including "bad" transactions. Rationally the attack would have to cost about as much as the extra revenue from censored fees, but risk aversion would probably leverage to this strategy.
Of course I'd rather not go down this path.
- Sjors
Peter Todd
Jun 3, 2025, 2:31:07 PMJun 3
to Chris Guida, John Carvalho, bitco...@googlegroups.com
On Mon, Jun 02, 2025 at 08:52:15PM -0600, Chris Guida wrote:
> "NODE_LIBRE_RELAY" is not defined anywhere in bitcoin core or any other
> official documentation. Bit 29 is just a random bit reserved for future
> use, as far as the bitcoin protocol itself is concerned. So when Peter says
> Garbageman "falsely advertises the NODE_LIBRE_RELAY service bit", this is
> incorrect. It is not possible for GM or any other software to misuse this
> bit, as it has no official significance.
This is Bitcoin: there is no "official documentation".
> "NODE_LIBRE_RELAY" is not defined anywhere in bitcoin core or any other
> official documentation. Bit 29 is just a random bit reserved for future
> use, as far as the bitcoin protocol itself is concerned. So when Peter says
> Garbageman "falsely advertises the NODE_LIBRE_RELAY service bit", this is
> incorrect. It is not possible for GM or any other software to misuse this
> bit, as it has no official significance.
What things mean is defined by customary usage. Which in this case is pretty
clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.
> Peter himself, using Libre Relay, was ultimately responsible for getting
> this option defaulted to “on” in core, by taking the battle directly to the
> mining pools. What the anti-filter crowd does not seem to realize is that
> Peter never would have succeeded if the noderunner community had been
> opposing him on this.
full-rbf for a very long time: hardly any nodes relayed full-rbf replacements
until Bitcoin Core decided to turn it on by default.
As with Libre Relay, I maintained a full-rbf peering fork of Bitcoin Core,
advertising a FULL-RBF service bit, and a sufficiently large minority ran that
fork to relay full-rbf replacements to the miners that were interested in them.
As with Libre Relay, many of those miners didn't actually run that fork
themselves, and instead privately peered with my full-rbf peering nodes to
ensure they got the transactions they were interested in.
Funny enough, Bitcoin Knots also sybil attacked full-rbf peering, probably
unintentionally: Knots advertises the full-RBF peering bit without actually
doing the peering that makes the service bit worthwhile. For awhile there were
a sufficiently large number of Knots nodes that an actual full-rbf peering node
would tend to have only Knots nodes as peers. While at the same time, there
weren't enough Knots nodes to reliably propagate full-RBF replacements.
I fixed this problem by running a dozen or so genuine full-RBF peering nodes,
each on a different VPS, and thus diverse address space (I went through a list
of Bitcoin accepting VPS's, and bought one from pretty much every VPS provider
I could find in Ukraine - obviously their ISPs could use the revenue right
now).
> Yes, I’m sure there are strategies for getting LR nodes to detect GM nodes
> and banning them. And I’m equally sure that, if implemented:
>
> 1) Very few people will run them. Only LR nodes are likely to run the
> garbage-maximizing strategies Peter outlined above. I don’t know of any
> noderunners in their right minds who would run them.
> 2) The pro-spam-filtration noderunner community will work around these
> detection methods any way we can, and we will never give up.
anti-censorship mechanism of measuring total fees relayed. That's a decent sign
that it does in fact work and garbageman has no way to defeat it.
Anyway, I think this conversation risks wasting the time of everyone on this
list, as you don't actually have anything technical to say. But I will say,
once cluster mempool is merged in Bitcoin Core, I'd be open to working with
anyone interested in either funding or implementing this (ideally as a pull-req
to Bitcoin Core - all Bitcoin nodes have an interest in bypassing censorship of
transactions they accept).
Sjors Provoost
Jun 3, 2025, 5:08:43 PMJun 3
to Peter Todd, bitco...@googlegroups.com
After some back-of-the-envelope calculations*, I agree that this pointless.
But it does seem that the first-seen rule is quite useful. For an attacking pool with fraction f, it reduces their success rate from linear with f to quadratic.
Although theoretically that's worse for small pools, it doesn't really matter in practice, because the odds of a successful reorg are tiny anyway. Even if the attacking pool allocates 10% of its hash power, which would be very hard to sustain in a competitive environment.
* = too sloppy to be worth sharing. Someone actually competent at math could do so. The strategy would be to mine an alternate chain for n seconds after each "bad" block (regardless of new blocks coming in). If the pool finds a block, it keeps mining on it until a longer chain appears. Compare this strategy with and without the first-seen rule in place, otherwise assume instant propagation. Then consider how many sats of transaction fees the other miners should rationally be willing to forgo to avoid the reorg risk.
- Sjors
--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CC0C1719-662E-4571-97EE-4DC504CC4360%40sprovoost.nl.
Chris Guida
Jun 5, 2025, 8:56:17 AMJun 5
to Peter Todd, John Carvalho, bitco...@googlegroups.com
>What things mean is defined by customary usage. Which in this case is pretty
clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.
I don't think a handful of nodes using a random service bit for a couple of years qualifies as "customary". The vast majority of nodes do not even parse this bit.
>This is nonsense. In a sense, the noderunner community *was* opposed to
full-rbf for a very long time: hardly any nodes relayed full-rbf replacements
until Bitcoin Core decided to turn it on by default.
full-rbf for a very long time: hardly any nodes relayed full-rbf replacements
until Bitcoin Core decided to turn it on by default.
This is merely a reflection of core's defaults which, indeed, are quite sticky. But everyone I spoke to who understood the issue decided to turn fullrbf on. You probably could have succeeded with just a bit more lobbying of the node network, without using LR at all. But, sure, LR was faster.
>Sounds like you don't actually have anything to say about my proposed
anti-censorship mechanism of measuring total fees relayed. That's a decent sign
that it does in fact work and garbageman has no way to defeat it.
anti-censorship mechanism of measuring total fees relayed. That's a decent sign
that it does in fact work and garbageman has no way to defeat it.
All of your mitigations can be countered with just more GM nodes. "Private peering" is not defeated by GM, but that's really no more impactful than direct-to-miner submission anyway. That is countered by assuming that less than half of hashrate is hostile, which is the base assumption of bitcoin anyway. If true, this assumption means that at most half the hashrate will mine abusive txs, which means they will always be at least 2x more expensive on average.
>Anyway, I think this conversation risks wasting the time of everyone on this
list
list
I am down to move this conversation to a different venue if you can suggest a better one.
>as you don't actually have anything technical to say.
Yes Peter, I didn't say "anything technical". Not a single thing xD
--Chris
Peter Todd
Jun 5, 2025, 8:56:34 AMJun 5
to Chris Guida, John Carvalho, bitco...@googlegroups.com
On Wed, Jun 04, 2025 at 02:16:23PM -0600, Chris Guida wrote:
> >What things mean is defined by customary usage. Which in this case is
> pretty
> clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.
>
> I don't think a handful of nodes using a random service bit for a couple of
> years qualifies as "customary". The vast majority of nodes do not even
> parse this bit.
You admit that Libre Relay nodes customarily use that service bit: as you
> >What things mean is defined by customary usage. Which in this case is
> pretty
> clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.
>
> I don't think a handful of nodes using a random service bit for a couple of
> years qualifies as "customary". The vast majority of nodes do not even
> parse this bit.
openly claim, the whole point of garbageman is to perform a sybil attack
against the nodes using that service bit.
> >This is nonsense. In a sense, the noderunner community *was* opposed to
> full-rbf for a very long time: hardly any nodes relayed full-rbf
> replacements
> until Bitcoin Core decided to turn it on by default.
>
> This is merely a reflection of core's defaults which, indeed, are quite
> sticky. But everyone I spoke to who understood the issue decided to turn
> fullrbf on. You probably could have succeeded with just a bit more lobbying
> of the node network, without using LR at all. But, sure, LR was faster.
people running nodes: what matters is what nodes actually did. As I said, the
vast majority of nodes were running with full-rbf relaying off until Bitcoin
Core changed the defaults. That was technical opposition, and full-rbf peering
code defeated that opposition.
> >Sounds like you don't actually have anything to say about my proposed
> anti-censorship mechanism of measuring total fees relayed. That's a decent
> sign
> that it does in fact work and garbageman has no way to defeat it.
>
> All of your mitigations can be countered with just more GM nodes. "Private
> peering" is not defeated by GM, but that's really no more impactful than
> direct-to-miner submission anyway. That is countered by assuming that less
> than half of hashrate is hostile, which is the base assumption of bitcoin
> anyway. If true, this assumption means that at most half the hashrate will
That's just not how fees work: https://opreturnbot.eldamar.icu/
> >Anyway, I think this conversation risks wasting the time of everyone on
> this
> list
>
> I am down to move this conversation to a different venue if you can suggest
> a better one.
>
> >as you don't actually have anything technical to say.
>
> Yes Peter, I didn't say "anything technical". Not a single thing xD
your discussion: your just making a bald assertion that "All of your
mitigations can be countered with just more [garbageman] nodes." You're not
making a concrete technical claim here. You're just saying that. And you add to
that nonsense with an entirely unrelated and irrelevant digression about hash
power.
Here's what an actual technical analysis would look like:
Suppose that there does *not* exist a Libre Relay service bit. For sake of
argument, let's say that the only mechanism that Libre Relay nodes find each
other is via next-double-block total fee advertisements. We'll also assume that
*all* nodes support this mechanism. Every t seconds on average, assume that a
Libre Relay node drops its peer advertising the smallest total
next-double-block fee, and tries a different peer.
Since there is no Libre Relay service bit, garbageman nodes are in fact
irrelevant to this discussion. As I covered in my previous writeup, total fee
advertisements can't be fooled: either you do in fact propagate the
transactions whose fee you advertise, or you don't. If you lie, you're node is
going to be banned.
Finally, let's assume that there are always enough extra Libre Relay
transactions to make a "noticable" difference to peering. Basically, enough
extra fees that the extra fees show up over the inevitable noise you'll see in
peering policies.
If the ratio of nodes without Libre Relay peering policies to nodes with Libre
Relay peering policies is q, the total average time it will take for a node to
find another Libre Relay compatible peer is just q*t.
For example, if t=120s, and q=1000, (e.g. 40 nodes out of the ~40,000 IPv4
listening nodes that bitnodes.io is reporting at the moment) it'll take 1.4
days on average for a Libre Relay node to find another compatible peer. Not
particularly fast. But even in this circumstance, with a 1000-to-1 ratio
against you, Libre Relay nodes would have a decent set of peers in a week. And
obviously, we can improve that time further by connecting to more peers and
trying to find two or three better ones at once.
Peter Todd
Jun 5, 2025, 8:57:14 AMJun 5
to Greg Maxwell, Sjors Provoost, bitco...@googlegroups.com
On Tue, Jun 03, 2025 at 05:00:42PM +0000, Greg Maxwell wrote:
> 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.
I want to emphasize that this type of threat is not theoretical.
> 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.
Court-Confirmed Fraudster Craig Wright did in fact sue us in an effort to
recover alleged stolen coins. If courts perceive a history of Bitcoin Core
developers actively trying to prevent "undesirable" transactions, then there is
a very real chance for courts to order Bitcoin Core developers to do things
like freeze addresses, even though if anyone posted such a pull request it
would be ineffectual because people wouldn't choose to run it. Still the order
would be highly disruptive to people and the project. The community should want
every protection available to prevent future court actions like that from being
considered, issued or succeeding. A history of actively trying to prevent
"undesirable" transactions does not help.
It's notable that this advocacy from filtering is coming from a pool that
claims to offer decentralized mining via the DATUM protocol. Yet hasn't even
taken the most basic step to actually achieving that: releasing the full DATUM
source code. If a court orders miners to run an extension of Knots with
specific addresses censored, DATUM will do absolutely nothing to stop that:
DATUM currently has OCEAN approving blocks - allowing OCEAN to reject shares
mining censored addresses. Without the ability to spin up competitors to OCEAN,
miners wishing to contribute uncensored hash power can do nothing other than
hope someone decided to rewrite, from scratch, all the closed-source OCEAN code
making DATAUM actually work.
If you're actually serious about decentralization, open-source OCEAN.
Rijndael
Jun 7, 2025, 9:55:00 AMJun 7
to Peter Todd, Chris Guida, John Carvalho, bitco...@googlegroups.com
On Jun 3, 2025, at 1:58 PM, Peter Todd <pe...@petertodd.org> wrote:What things mean is defined by customary usage. Which in this case is pretty
clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.
garbageman seems to concur it’s the NODE_LIBRE_RELAY service bit: https://github.com/chrisguida/bitcoin/blob/garbageman/src/init.cpp#L924 https://github.com/chrisguida/bitcoin/blob/60ae68d42dc0615ea2b83a4614636ff83178e0c0/src/protocol.h#L341
—
rijndael
Chris Guida
Jun 9, 2025, 6:54:45 AMJun 9
to Greg Maxwell, Sjors Provoost, bitco...@googlegroups.com
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
--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgT3gyra4BNN1zDVz%3Dn%3DtmteZLC4xuzTWSm_s0T6Rw2MJA%40mail.gmail.com.
Chris Guida
Jun 9, 2025, 6:54:45 AMJun 9
to Sjors Provoost, bitco...@googlegroups.com
Hi Sjors, thanks for the thoughtful response.
>More importantly it doesn't contain any numerical analysis as to its effectiveness.
Well, as I said, I think Peter's analysis is sufficient, and I don't think there's much for me to add. It seems to me that Peter's analysis effectively comes down to relative numbers of LR vs GM nodes. GM nodes will always be able to detect LR nodes, but the reverse is not necessarily true. To illustrate this point: once the arms race has advanced sufficiently, it may only be possible to really detect the difference between GM and LR during a spam attack, as spam filtration is just rate-limiting, not censorship. This means that, since merely rate-limiting abusive transaction types is sufficient to protect the network against spam attacks such as the ones we saw from BRC-20 and Runes, GM nodes might relay low volumes of spammy transaction types, because low-volume spam, while undesirable, is not really harmful. Again, as I tried to emphasize in my prior message, the goal is not to censor; the goal is to rate-limit spam.
Given this, it is unlikely that LR nodes will be able to reliably detect GM nodes, except during high-volume spam attacks, and at that point, why is LR still facilitating the attack?
>Presence on the OFAC list is an objective criterion. Your distinction
between "objective" and "subjective" seems rather arbitrary.
This is a valid criticism; you are correct that this point warrants clarification.
When I say "subjective", what I mean is that some authority has arbitrarily decided that certain transaction types are undesirable, without evidence of actual harm to bitcoin. OFAC is an example of such an arbitrary criterion. OFAC transactions do not harm bitcoin in any way, as bitcoin's purpose is to be permissionless money. Thus bitcoin infrastructure providers should not worry about whether some political authority has decided that certain actors should not be able to send money. That is up to law enforcement, not the payment network.
Conversely, inscriptions and runes are two examples of transaction types that have produced measurable harm to the bitcoin network. This is not a matter of subjective opinion, but rather of incontrovertible historical fact. I have already produced evidence of this fact in my prior message, which anyone can verify because it is public.
>In any case
it's not relevant for the purpose of censorship resistance.
It's relevant, because certain transaction formats are known to be harmful (ie those associated with Ponzi metaprotocols), and others are not. In the context of censorship resistance, if transaction formats that have no objective possibility of harming bitcoin are prohibited, then censorship has occurred. On the other hand, if transaction formats that are objectively known to be harmful are rate-limited, then no censorship has occurred; rather, spam filtration has occurred. Again, I'm trying to draw a clear distinction between censorship and spam filtration, because the former should be considered harmful and the latter should be considered good and necessary.
I hope that clarifies this point.
>The reality is that there are different groups using Bitcoin and they
have different opinions on which transactions it should include.
Yes, and we should rate-limit transaction formats where there exists a rough consensus that they are harmful (rough consensus being a proxy for objectivity), while we should not rate-limit transactions that objectively do not cause harm. Groups that "use bitcoin" in objectively harmful ways should not have a seat at the table.
>Governments are one such group and they could decide tomorrow to spin up
a bigger version Garbageman and disrupt the entire mempool. If they
perceive it as an attack on their interest.
Can you go more into detail about the attack that concerns you here? There are a number of issues with the scenario you outlined here:
What is a "bigger version of Garbageman"? As I already explained above, Garbageman does nothing to censor anything. It does not "disrupt the mempool" at all. It merely acts as a counterbalance to LR, which has an extremely liberal mempool policy. On the contrary, LR is "disrupting the mempool" by filling it with junk. GM neutralizes this disruption.
Is your concern that the USG would spin up a bunch of GM nodes that don't relay transactions from OFAC addresses? As I've already detailed, this would be completely ineffective, as anyone can get a single transaction confirmed if they want. There is no way the government could effect censorship against OFAC addresses unless literally 100% of the hashrate is filtering such transactions.
In addition to this, there have been pools (to wit, F2Pool and Mara) that have started filtering OFAC transactions, and there was an immediate backlash against this activity, because again, OFAC transactions are objectively not harmful to bitcoin, and censoring them would be objectively harmful to bitcoin. Neither of the pools mentioned above is filtering OFAC transactions anymore. This is a well-documented example of social pressure preventing mining pools from harming bitcoin in order to bolster their medium-term profits.
>As a result everyone has to
submit transactions directly to a handful of, often US based, pools.
Can you elaborate? I'm not seeing how this would work. Again, as long as there is one pool willing to confirm OFAC transactions, the censorship is not effective. I'm not seeing how US authorities could compel users to use only US-based pools.
>If we're going down the route of openly innovating attacks against the
mempool, we should also continue innovating countermeasures, as Peter
Todd did.
I am perfectly fine with devs continuing to innovate methods of avoiding censorship on bitcoin; this will certainly come in handy if "authorities" attempt to censor bitcoin. But again, I don't see GM as "innovating attacks against the mempool", nor do I see it as a viable tool for censorship. GM has exactly the same mempool policy as Knots, and no one considers Knots to be "innovating attacks against the mempool". It just follows the same effective mempool policy as has been in place for over a decade. GM is merely a countermeasure against LR, which is a danger to bitcoin.
>This is extremely vague and avoids the question of effectiveness. What percentage of attempted "spam" transactions are prevented from entering a block? What's the average delay in seconds?
This would be hard to measure, because the rate-limiting comes from increasing the cost in money, time, and frustration on the spammers. Since I am not a spammer, it would be difficult for me to conduct an experiment to see how fast my demand falls in proportion to the costs imposed. But it would be completely absurd to imagine that demand for spam is completely inelastic; that is, that demand would never fall regardless of the costs imposed. Economic theory and historical evidence both soundly refute this notion.
>You speak of "rate limiting", but delaying propagation doesn't rate
limit anything. Unless you completely block some percentage of
transactions, the same amount of spam ends up in blocks, just a little
bit later. The rate, e.g. gigabytes per months, stays the same.
Again, this is simply incorrect. Spam does not have inelastic demand. Spam filtration is a deterrent, which means that its mechanism of action is precisely that it reduces demand. You seem to be implying that, no matter what the cost, a spammer who wants to get a transaction confirmed will never give up. This claim is exceedingly dubious. If one analyzes the problem in the context of supply and demand, it is not hard to understand why.
If a certain percentage of the hashrate is confirming spam, let's say 20%, then that implies that the cost to get a spam transaction mined is much higher than the cost of a normal transaction. Specifically, since the supply of block space available for normal transactions is 5x higher than for spam transactions, we can expect the cost of a spam transaction to be 5x higher and/or to take 5x longer to confirm. This is just basic economics.
And again, it is a matter of uncontroversial historical fact that filters reduce economic demand for the transaction formats they reject. See [0] for stats about a filter that is doing a fantastic job.
>If the "spammers" use extremely naive software, perhaps they never try
again and the sybil attack was successful. But this assumes an adversary
who doesn't adapt, which is not a reasonable assumption.
The "adversary" here is scammers and their gullible marks. They can run their Ponzis on other chains much more easily than they can run them on bitcoin, and they are lazy. If we just treat them with the hostility they deserve, they will just give up and spam some other chain, as they did from 2014-2023.
>Anyone would understand from their own experience if that if a
transaction doesn't go through, you try again. You don't just accept
that you've been rate limited.
Again, to a point. There is a certain threshold of costliness beyond which people just say "man, this isn't worth it, let's go spam ETH instead". And again, bitcoin achieved this for 9 years.
>The simplest next move would be for their software to just connect to
more Libre relay peers and broadcast the transaction again.
Yep, that's where Garbageman comes in! If all LR peers are eclipsed by GM peers, then this does nothing.
>Or people can just spin up more Libre Relay nodes.
Who are these people? Altcoiners?? Yeah, right. Anyway, we can just spin up more GM nodes.
>Both miners and issuers of various scam tokens have a monetary incentive to do that.
If miners do this, then they are hostile. If >50% of miners are hostile, then bitcoin is dead.
>Whereas proponents of filters are (so far) not willing to invest serious money.
I wouldn't be so sure about that.
>E.g. when I challenged Luke Dashjr in an earlier post to reorg a single block with spam, he didn't respond
As Peter and you yourself noted, this is unfair to Ocean.
>Worse, Ocean proactively offers "Core" [0] templates
Yes, this is another reason why it would be silly for Ocean to try to "do" anything with its hashrate; a large portion of its hashpower is making its own templates.
>Although running a node is cheap, if this becomes an arms race, the side that actually spends money has the advantage.
I disagree. I think the side that wants bitcoin to survive has the advantage, because we are going down with the ship. As previously noted, spammers are not at all invested in bitcoin's success. We can do this all day. They can't.
>But let's say, after all this you find a way to make Garbageman
effective, that it actually causes and sustains an economically
meaningful delay between when a transaction is submitted to Libre Relay
network and when its included in a block. 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.
Again, if miners are doing this, then they are hostile. If >50% of miners are hostile, then we need to know right now because Nakamoto Consensus falls apart if >50% of the hashrate is dishonest. We already trust the miners not to try to 51% attack the network with their own new rules; why is burying bitcoin under a mountain of garbage any different, except for the fact that it's slower and less violent?
--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl.
Sjors Provoost
Jun 9, 2025, 6:54:46 AMJun 9
to Chris Guida, bitco...@googlegroups.com
Hi Chris,
I'm replying to a few points that matter imo.
Again, as I tried to emphasize in my prior message, the goal is not to censor; the goal is to rate-limit spam.
.
The tooling you're building is dual-use at best, and from a miner point of view it's censorship.
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.Again, if miners are doing this, then they are hostile. If >50% of miners are hostile, then we need to know right now because Nakamoto Consensus falls apart if >50% of the hashrate is dishonest.
Miners are simply following their incentives. It's merely your opinion that this is "hostile". The people who share your opinion have not presented a credible way of enforcing it. All they've achieved is collateral damage.
Is your concern that the USG would spin up a bunch of GM nodes that don't relay transactions from OFAC addresses?
No, they would take down the entire mempool by spinning up a million well connected fake nodes that behave in the same way your project does, except they drop *all* transactions. Since there's no financial incentive for users to run nodes, it'll be hard to counter this attack by merely spinning up more nodes.
>You speak of "rate limiting", but delaying propagation doesn't rate limit anything. Unless you completely block some percentage of transactions, the same amount of spam ends up in blocks, just a little bit later. The rate, e.g. gigabytes per months, stays the same.Again, this is simply incorrect. Spam does not have inelastic demand.
[...]
If a certain percentage of the hashrate is confirming spam, let's say 20%,
No, 100% will be confirming spam and nothing happens to the fee rate. Elasticity isn't an issue here.
Where does your 20% figure come from? Is that based on your assumption they are not "hostile" and would just go along with not receiving the extra revenue if your sybil nodes block it?
But why would 80% of miners throw away fee revenue? They won't, so both transaction makers and miners will go around your "rate limiting".
The thing that is concerning here is that they'll use centralised transaction submission services for this, and any miner that doesn't join such service loses revenue and goes out of business.
>Whereas proponents of filters are (so far) not willing to invest serious money.I wouldn't be so sure about that.
You're not providing any evidence to the contrary.
And again, Ocean Pool proactively added the "Core" template after they got pushback from customers for only offering Knots with filtering. After v30 that template will allow unlimited OP_RETURN. Perhaps they'll drop it then, but so far they haven't put a cent of revenue at risk.
>Or people can just spin up more Libre Relay nodes.Who are these people? Altcoiners?? Yeah, right. Anyway, we can just spin up more GM nodes.
This comes back to question of budget. Miners and scammers have budget for relay infrastructure. You can of course try to outspend them, with your own money or a rich donor. If you sustain that effort long enough, it may be cheaper for them to use centralised submission services. Which as others have pointed out is very bad.
- Sjors
Reply all
Reply to author
Forward
0 new messages