From: "James O'Beirne" <james.obeirne@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Anthony Towns <aj@erisian•com.au>,
Greg Maxwell <gmaxwell@gmail•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Weak blocks give an advantage to large miners
Date: Wed, 7 May 2025 20:42:51 +0000 [thread overview]
Message-ID: <CAPfvXf+2wkB6MyN6Bogr8c6G3uZq255Ec90qC4y5WxuEGoCPrg@mail.gmail.com> (raw)
In-Reply-To: <aBku-6CIjQKIQjRS@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]
This analysis excludes two important points:
1. If a small miner has a mempool that is marginally closer to a large
miner's, they will connect blocks found by that miner more quickly, making
their own mining operation more efficient.
2. A small miner benefits from becoming aware of (potentially large,
non-standard, or directly submitted) transactions because they may want to
make use of it in their own block templates for more revenue.
Bandwidth is rarely a limiting factor for template creators (as there are
many more expensive pieces of hardware required to have a competitive
mining operation), and so a miner may very reasonably decide that it's
worth trading some bandwidth (in the form of received weak blocks) for the
prospect of juicing their fee revenue and minimizing tip connection time.
On Mon, May 5, 2025 at 11:36 PM Peter Todd <pete@petertodd•org> wrote:
> On Mon, May 05, 2025 at 07:18:57PM +1000, Anthony Towns wrote:
> > I meant to mention this last email, but had forgotten where to find
> > the link. Personally, I think Greg's "relay extra transactions via weak
> > blocks" idea [0] from a year ago is an approach that should be considered
> > here. The TLDR is that if there are miners out there with different
> > relay policies than your node that are accepting transactions you'll
> > reject (eg, lower fee, new tx versions, more complicated dependencies,
> > ...) then once they find a relatively high PoW share, have the network
> > relay that as a weak compact block, with full round-trips to gather
> > any transactions that weren't in your mempool and add those txs to your
> > extra pool to help with block reconstruction in the near future.
> >
> > [0] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805/1
>
> Weak blocks give an advantage to large miners. Small miners, who rarely
> find blocks, are also going to rarely find weak blocks, making the
> feature mostly useless for them in terms of their choice of
> transactions, while simultaneously increasing bandwidth consumption
> somewhat. Meanwhile large miners do find weak blocks often, making the
> feature useful for them and making it even easier for them to profit by
> including non-standard transactions. Which again, is something that
> small miners can't do.
>
> --
> 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/aBku-6CIjQKIQjRS%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/CAPfvXf%2B2wkB6MyN6Bogr8c6G3uZq255Ec90qC4y5WxuEGoCPrg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4436 bytes --]
next prev parent reply other threads:[~2025-05-08 8:17 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
2025-04-30 15:37 ` Nagaev Boris
2025-04-30 16:30 ` Sjors Provoost
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-05-01 17:40 ` Andrew Toth
2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
2025-05-01 19:33 ` Nagaev Boris
2025-05-02 6:34 ` Anthony Towns
2025-05-02 18:29 ` Peter Todd
2025-05-03 5:14 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-01 3:01 ` Anthony Towns
2025-05-02 18:56 ` Greg Tonoski
2025-05-05 6:04 ` Bitcoin Error Log
2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-02 0:14 ` PandaCute
2025-05-02 11:16 ` [bitcoindev] " Sjors Provoost
2025-05-02 14:37 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-02 16:43 ` Greg Maxwell
2025-05-02 13:58 ` [bitcoindev] " Bob Burnett
2025-05-02 20:03 ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
2025-05-02 22:58 ` [bitcoindev] " Greg Maxwell
2025-05-03 2:02 ` Martin Habovštiak
2025-05-05 21:45 ` Peter Todd
2025-05-05 23:55 ` Greg Maxwell
2025-05-02 6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell
2025-05-02 9:51 ` Anthony Towns
2025-05-02 17:36 ` Greg Maxwell
2025-05-05 9:18 ` Anthony Towns
2025-05-05 21:34 ` [bitcoindev] Weak blocks give an advantage to large miners Peter Todd
2025-05-06 8:56 ` Sjors Provoost
2025-05-07 20:42 ` James O'Beirne [this message]
2025-05-02 20:43 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
2025-05-04 20:04 ` Nagaev Boris
2025-05-05 11:42 ` Greg Maxwell
2025-05-05 14:32 ` Nagaev Boris
2025-05-05 21:30 ` Peter Todd
2025-05-05 14:05 ` Greg Maxwell
[not found] ` <20250502064744.92B057C0EE2@smtp.postman.i2p>
2025-05-07 1:20 ` pithosian
2025-05-07 11:32 ` Greg Maxwell
[not found] ` <20250507121109.6CEA77C0AAF@smtp.postman.i2p>
2025-05-07 16:55 ` pithosian
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=CAPfvXf+2wkB6MyN6Bogr8c6G3uZq255Ec90qC4y5WxuEGoCPrg@mail.gmail.com \
--to=james.obeirne@gmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.com \
--cc=gmaxwell@gmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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