From: Murch <murch@murch•one>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte
Date: Mon, 3 Feb 2025 14:42:52 -0500 [thread overview]
Message-ID: <d7dd94f6-f76f-4fdb-9994-d3ee4fff7d75@murch.one> (raw)
In-Reply-To: <CAMHHROwmm0_+AOcBHj6Qrf07HWxzK0=ioeqf6nRf1kAqQhf5wg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2302 bytes --]
Hi Greg,
On 2025-01-31 08:43, Greg Tonoski wrote:
> I agree that -incrementalrelayfee=0 (or whatever suits a node runner)
> would logically supplement the minrelaytxfee=0.00000001.
Setting `incrementalrelayfee` to zero would mean that you allow the
replacement of an original transaction without increasing the total fees
in the mempool. A malicious actor could trivially exploit this setting
by cycling two conflicting transactions A and A' with the same weight
and same fee to waste bandwidth and CPU cycles across the nodes that
follow your advice.
On 2025-01-31 08:43, Greg Tonoski wrote:
> I suppose that miners already use -blockmintxfee=0 or anything lower
> than the default value because there are transactions with fees as low
> as 0 (zero) in the blocks.
Do you have any evidence for this claim? The prior times that I
investigated this claim, transactions with feerates lower than
`minTxRelayFee` exclusively appeared at the front of the block,
indicating that they were explicitly prioritized by the miner, probably
due to out-of-band payment. You may now also find some TRUC transactions
where a low-feerate parent is carried by a higher feerate child. Neither
of these two indicates that a miner has configured a lower `-blockmintxfee`.
You could convince me that a miner has configured a lower
`-blockmintxfee` by showing us a block that includes transactions with
feerates below `minTxRelayFee` appearing in the organic descending
feerate order.
On 2025-01-31 08:43, Greg Tonoski wrote:
> I can't see how minrelaytxfee=0.00000001 could increase risk of DoS
> attack or make it significantly cheaper or more effective. There are
> the default 300MB size limit for mempool and 336 hours timeout for
> unconfirmed txs. They limit impact of a low fee-rate txs DoS attack
> making it ineffective.
Unfortunately, not knowing about an exploit falls short of proving
something secure.
Murch
--
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/d7dd94f6-f76f-4fdb-9994-d3ee4fff7d75%40murch.one.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2025-02-03 20:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 8:49 Greg Tonoski
2025-01-31 12:54 ` Sjors Provoost
2025-01-31 13:43 ` Greg Tonoski
2025-01-31 14:40 ` Sjors Provoost
2025-01-31 15:13 ` Sjors Provoost
2025-02-03 19:42 ` Murch [this message]
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=d7dd94f6-f76f-4fdb-9994-d3ee4fff7d75@murch.one \
--to=murch@murch$(echo .)one \
--cc=bitcoindev@googlegroups.com \
/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