From: Sjors Provoost <sjors@sprovoost.nl>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man)
Date: Tue, 3 Jun 2025 22:32:56 +0200 [thread overview]
Message-ID: <024E3F99-20B0-4D86-BCEB-AED508221391@sprovoost.nl> (raw)
In-Reply-To: <CC0C1719-662E-4571-97EE-4DC504CC4360@sprovoost.nl>
[-- 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 --]
next prev parent reply other threads:[~2025-06-03 21:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-27 11:16 [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man) Peter Todd
2025-05-27 11:37 ` John Carvalho
2025-06-03 2:52 ` Chris Guida
2025-06-03 6:50 ` Sjors Provoost
2025-06-03 17:00 ` Greg Maxwell
2025-06-05 12:16 ` Peter Todd
2025-06-03 17:41 ` Peter Todd
2025-06-03 17:51 ` Sjors Provoost
2025-06-03 20:32 ` Sjors Provoost [this message]
2025-06-03 17:58 ` Peter Todd
2025-06-04 20:16 ` Chris Guida
2025-06-05 11:59 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=024E3F99-20B0-4D86-BCEB-AED508221391@sprovoost.nl \
--to=sjors@sprovoost.nl \
--cc=bitcoindev@googlegroups.com \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox