> Op 3 jun 2025, om 04:52 heeft Chris Guida <[email protected]> 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/[email protected]/ -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl.
