Delivery-date: Mon, 03 Feb 2025 12:34:53 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of murch@murch.one designates 185.26.156.114 as permitted sender) client-ip=185.26.156.114;
Message-ID: <d7dd94f6-f76f-4fdb-9994-d3ee4fff7d75@murch.one>
Date: Mon, 3 Feb 2025 14:42:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [bitcoindev] Call for reconfiguration of nodes to relay
 transactions with fee-rates below 1 sat/vbyte
To: bitcoindev@googlegroups.com
References: <CAMHHROxVo_7ZRFy+nq_2YzyeYNO1ijR_r7d89bmBWv4f4wb9=g@mail.gmail.com>
 <A8F96312-613D-4090-B6C9-0A4C41418986@sprovoost.nl>
 <CAMHHROwmm0_+AOcBHj6Qrf07HWxzK0=ioeqf6nRf1kAqQhf5wg@mail.gmail.com>
Content-Language: en-US
From: Murch <murch@murch.one>
In-Reply-To: <CAMHHROwmm0_+AOcBHj6Qrf07HWxzK0=ioeqf6nRf1kAqQhf5wg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Cszwf2c8jftVz8St7bVO9K4S"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Cszwf2c8jftVz8St7bVO9K4S
Content-Type: multipart/mixed; boundary="------------KHguq23So8hlia0y66QSsKm0";
 protected-headers="v1"
From: Murch <murch@murch.one>
To: bitcoindev@googlegroups.com
Message-ID: <d7dd94f6-f76f-4fdb-9994-d3ee4fff7d75@murch.one>
Subject: Re: [bitcoindev] Call for reconfiguration of nodes to relay
 transactions with fee-rates below 1 sat/vbyte
References: <CAMHHROxVo_7ZRFy+nq_2YzyeYNO1ijR_r7d89bmBWv4f4wb9=g@mail.gmail.com>
 <A8F96312-613D-4090-B6C9-0A4C41418986@sprovoost.nl>
 <CAMHHROwmm0_+AOcBHj6Qrf07HWxzK0=ioeqf6nRf1kAqQhf5wg@mail.gmail.com>
In-Reply-To: <CAMHHROwmm0_+AOcBHj6Qrf07HWxzK0=ioeqf6nRf1kAqQhf5wg@mail.gmail.com>

--------------KHguq23So8hlia0y66QSsKm0
Content-Type: text/plain; charset="UTF-8"; format=flowed

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.

--------------KHguq23So8hlia0y66QSsKm0--

--------------Cszwf2c8jftVz8St7bVO9K4S
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEENfStpiPrn+OjvH72e6A1yluQFxMFAmehHDwACgkQe6A1yluQ
FxNB3A/+NHbE3SIqf9GHGl5zX7dGv9f8IWHH8SGopeX3yrAVjBtdyqbVwz+eBPBI
Zf3WriD3goHhOKjUE5ziTLnseaaOW5UvF+iZ/RnUvW/uJAwFRqEjJkppC/7B4Ait
2tKDijaWtqjWiIRqkbBGeAouV2z64pkFWexsA2mTn1CIjQpGQ9dk26ak31V+uWRW
2Qqbw5McdgISfcOplWoUTATb0cBy1l/9qbJbGmKDPGE3px3Zv6/Gejjp6ixP2wrF
pKG7dQgiff/n4hbgTbqmjwL97AoTRlCBdNPI3itNhw7CWsTHnOs8ozHFH/eYRkf0
O69isCFnMYF7J7dggJSs9aXUTC817cRcIXIYCTyThy19EBYCRXKgO3N9qCUFygwz
m+l2egtwONyPRwZtkWb9+DoJ8C5PynUExMv9Gsx9Ly8IHy0nFyP/U3IiswGB4iAd
wuDz4BF9AfySxdGi3pdC/6YhyYSOpmHhOe6x+mFgoTn7wsiyinaJnVDyxPGp7pfY
2EtXJmuyIV7iJrOmFZuj46YNhWX1+Enrpv/3CEGs9aqfcmGNoCmU/Wk2kw8BV2QS
y3cDczrTYSbWAo83uc73pyFmZ5qSPwrWcYsLjocpU8mw6OZxEpXhz3SsUjTk9HJ6
YtZEfGkdeAcUYCH+vh7LvlxlSUkBACRKRh9fuaohpHt9NByoqk0=
=hfRa
-----END PGP SIGNATURE-----

--------------Cszwf2c8jftVz8St7bVO9K4S--