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

From: Sjors Provoost <[email-masked]>
Date: Tue, 3 Jun 2025 22:32:56 +0200

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 <[email-masked]> 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 <[email-masked]> 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 [email-masked].
> 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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/024E3F99-20B0-4D86-BCEB-AED508221391%40sprovoost.nl.