Re: [bitcoindev] Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte

[Murch <murch@murch.one>]

[-- 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 --]