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

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

[Peter Todd]

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

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

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[John Carvalho]

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

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:
-
https://medium.com/pubky/public-key-domains-censorship-resistance-explained-33d0333e6123
- https://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb

Maybe this helps you, or others looking for such primitives!

--
John Carvalho
CEO, Synonym.to <http://synonym.to/>



On Tue, May 27, 2025 at 12:23 PM Peter Todd <pete@petertodd.org> wrote:

> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40petertodd.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com.

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

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

[Chris Guida]

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

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*

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

On Tue, May 27, 2025 at 5:42 AM John Carvalho <john@synonym.to> wrote:

> 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:
> -
> https://medium.com/pubky/public-key-domains-censorship-resistance-explained-33d0333e6123
> - https://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb
>
> Maybe this helps you, or others looking for such primitives!
>
> --
> John Carvalho
> CEO, Synonym.to <http://synonym.to/>
>
>
>
> On Tue, May 27, 2025 at 12:23 PM Peter Todd <pete@petertodd.org> wrote:
>
>> 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
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40petertodd.org
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAANnUwHcd1w6phwyfDKebzEabAtm%3DA3i2qkLDpJ9L47q75T9Q%40mail.gmail.com.

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

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

[Sjors Provoost]

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


> Op 3 jun 2025, om 04:52 heeft Chris Guida <chrisguida@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

[0] https://ocean.xyz/docs/templateselection
[1] https://gnusha.org/pi/bitcoindev/f348e4bf-ccc4-48e3-9745-ac72b1b131f5@app.fastmail.com/

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl.

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

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

[Greg Maxwell]

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

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

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

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

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

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

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

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

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

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

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgT3gyra4BNN1zDVz%3Dn%3DtmteZLC4xuzTWSm_s0T6Rw2MJA%40mail.gmail.com.

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

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

[Peter Todd]

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

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

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aEGKu4u8B03Tiy26%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Peter Todd]

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

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

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aD8z34hk6IQ21cSv%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Sjors Provoost]

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 

> Op 3 jun 2025, om 19:41 heeft Peter Todd <pete@petertodd.org> het volgende geschreven:
> 
> 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
> 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.
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CC0C1719-662E-4571-97EE-4DC504CC4360%40sprovoost.nl.

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

[Sjors Provoost]

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

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

> Op 3 jun 2025, om 19:51 heeft Sjors Provoost <sjors@sprovoost.nl> het volgende geschreven:
> 
> 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 
> 
>> Op 3 jun 2025, om 19:41 heeft Peter Todd <pete@petertodd.org> het volgende geschreven:
>> 
>> 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
>> 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.
>> 
>> -- 
>> https://petertodd.org 'peter'[:-1]@petertodd.org
> 
> -- 
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CC0C1719-662E-4571-97EE-4DC504CC4360%40sprovoost.nl.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/024E3F99-20B0-4D86-BCEB-AED508221391%40sprovoost.nl.

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

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

[Peter Todd]

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

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

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.

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.

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.

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.


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

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aD83wBeeuZ32bGjz%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Chris Guida]

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

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

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.

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

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

On Tue, Jun 3, 2025 at 11:58 AM Peter Todd <pete@petertodd.org> wrote:

> 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".
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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).
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAANnUwW%3DkXx1Nfgf4dyhSjh%2B-hf%2B3UB53jKvEPs3OUQbncz2A%40mail.gmail.com.

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

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

[Peter Todd]

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

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

Bitcoin's technical functioning has nothing to do with the state of mind of
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
> expensive on average.

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

What you just said above is a great example of the lack of technical rigor in
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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aEGGjeC9FxJS0Sxt%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]