From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 08 Jan 2026 10:19:38 -0800 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vdubh-0001GL-J6 for bitcoindev@gnusha.org; Thu, 08 Jan 2026 10:19:38 -0800 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-3fa124db464sf5913288fac.1 for ; Thu, 08 Jan 2026 10:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1767896371; x=1768501171; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=EUcmMEHRFSwk1lo1Vl8DWiinM4jig0tz/RnPSI+Z14A=; b=nccUA/JsSy51b2qLwqK3gyiMgH8ZJzlEmcXEbEs8uFp3BLP6aKZPEGyTRmAQJeTr/i ZhAa22C2J72fOa9uohj1Xyh7ILMPH41risLcgqzJ9ZIcCWGMeskh6VlZ+/BwfNaPGas7 50PYdh/SXLn7QmdpaFk+v+pqjPB/IahyJj+VzMWQsfnpZ+J2EzbIeoTxMQxjl0BdOjyo 8B7wr9rz0JmcY4BpZCKaFb4sjcL9q3yi4SiZHZIqwFGmGylytrq6siuykW9vyPZX2KjR ZmZV2Nm13EaXPNNjQRiCXLtZea0IAjyqHBBOyRPWN4Ni+yWDm09s5ENlw9QmDPY3/Q0F sKLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767896371; x=1768501171; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=EUcmMEHRFSwk1lo1Vl8DWiinM4jig0tz/RnPSI+Z14A=; b=jCdoII4EX2IepemfyGTwkgk9pWGO8L21rqsU86N5dOjizjGaCZcRUiU1LTVaHN5OER AwnMuf3uXGzDfrxfsDcywiz2ycozdHkk2b0dX33r24G3jHEvCeQNxCKIawSyXBz7U6Oy +H8202Rf9eT6YNB1/ECA6c2OWd7yctnPrjbmMNKuB9cEeFNMb301C7DlbfpD9aZUZkSH PSZreQyWstnQCpX/lvSwQ6iZLnhKEhAjGPRfrLyrJ3gIU9LPP6+3mzl9rCt/QGtUuP+i JREHCzTngO725eQKoIRWz2pF68J4lCUntDPAis2FJn293hlK+YI4fBB53SlAZiUMmuso jOFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767896371; x=1768501171; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=EUcmMEHRFSwk1lo1Vl8DWiinM4jig0tz/RnPSI+Z14A=; b=bO5SrX2WklAtjY9BXIyKSHEZXS5w5g1czREjUnokAR5AocpqQSuxBGHaDGyNHJ+qGK 3ZHNGKN3aOs2KWGNgywQ5az153VuXPcON3HCu31apqV7l0NNgqkYRw3k6U7J57Ae0XA8 jwk9HPQigbmeQdi4eRtFc/ZAjI5B/djAP8tcO6PE2yXsFlzdVwZj2baVVwFxg2Id/F+u 52PPJXqJY3NSmEaHo5zIv/cVKWuX/vXt+youn67bD0EMG7wyqt/kZ2+7DyYUpee1Fz8k vug3XVS8qGdh8aT2Sbqps1xqizwQirxqkJFqfOZjKbqWlcyVTpDaQ1ae8z/l2B956GQC W/4g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWQeUVyNFYxos3CxlPL8sw5xnvsCKk8ahgDcuMuTjWEztkBJethZ+s5pXqOyfHdK03UCWcLO5Frgtvs@gnusha.org X-Gm-Message-State: AOJu0YyqqNw7/iGeXifN38/7LaG1dPxUJfwY87qjA02b6vi8UMO9tKTL Jlugyd9Zn1li4bLuuHg++YaLPPHWOzqH9Ivlu0RGzSKfWX+qoB3LMeun X-Google-Smtp-Source: AGHT+IH/Fro9TSMHxm6wDPOKWvRTLbBCJQJxqy/R36gQ31av89hztyc2UIOwrCA/jW+q3E4saGeg6w== X-Received: by 2002:a05:6871:5b0a:b0:3ec:2fe5:2b44 with SMTP id 586e51a60fabf-3ffc0a36712mr3467851fac.26.1767896370986; Thu, 08 Jan 2026 10:19:30 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWa0UQGFEJIw0TdKSTv03ljwAYrekcVlnt19lmAqMGwwRg==" Received: by 2002:a05:6871:2cf:20b0:3ec:401f:488b with SMTP id 586e51a60fabf-3ff9dbbc472ls1495592fac.1.-pod-prod-03-us; Thu, 08 Jan 2026 10:19:26 -0800 (PST) X-Received: by 2002:a05:6808:4f07:b0:459:b569:7505 with SMTP id 5614622812f47-45a6bcd42acmr3458955b6e.7.1767896365917; Thu, 08 Jan 2026 10:19:25 -0800 (PST) Received: by 2002:a05:690c:a7d7:b0:78f:a657:960d with SMTP id 00721157ae682-78fb3b6605cms7b3; Thu, 8 Jan 2026 10:13:06 -0800 (PST) X-Received: by 2002:a05:690c:6605:b0:790:ade2:936f with SMTP id 00721157ae682-790b56a5cd1mr70411107b3.37.1767895985800; Thu, 08 Jan 2026 10:13:05 -0800 (PST) Date: Thu, 8 Jan 2026 10:13:05 -0800 (PST) From: =?UTF-8?Q?Matthew_Hus=C3=A1k?= To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <7992d314-c068-4bea-b3da-03d65ea2d334@murch.one> References: <7992d314-c068-4bea-b3da-03d65ea2d334@murch.one> Subject: Re: [bitcoindev] BIP Idea: incrementalrelayfee in feefilter? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_838904_1433480145.1767895985196" X-Original-Sender: matejocraftak@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_838904_1433480145.1767895985196 Content-Type: multipart/alternative; boundary="----=_Part_838905_797874713.1767895985196" ------=_Part_838905_797874713.1767895985196 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Murch! thanks for such quick response. I think that we've been one of the first wallets to support such lower=20 fees, so we faced the initial "pain" to find peers with the lower=20 minrelaytxfee. That kinda made me feel that this has to change, because=20 when we solved the peers config (with our desired minrelaytxfee setting) we= =20 realized that many nodes (before the update) forgot to change the=20 minincrementalfee policy and since you can't check for peer's=20 minincrementalfee it makes the adoption even harder, because it's almost=20 impossible to find peers on your own (you could sign a RBF tx bumped up to= =20 fee under 1sat/vb and try to send it to different peers, but thats far from= =20 ideal :-D). I'm not sure if lowering the defaults will ever happen again, but I believe= =20 that you should be able to see under what conditions other nodes relay, so= =20 that you don't spam them with tx they don't want and so that the adoption= =20 is easier. I haven=E2=80=99t seen BIP 153 before, so I=E2=80=99ll read it and try to u= nderstand it.=20 That said, I have two ideas: the simplest is to expose=20 incrementalrelayfee , and the second (I=E2=80=99d love your opinion on thi= s) is=20 adding the ability to configure the node to actively seek peers meeting=20 specific minrelaytxfee and minincrementalfee thresholds=E2=80=94since A= FAIK it=20 currently settles for ~10 outbound nodes of any config, this would let it= =20 target at least 2 high-quality peers with those minimums during discovery. (or I could be totally off with my ideas :-D but I hope its not that case) Thanks! Matt Dne st=C5=99eda 7. ledna 2026 v 20:54:11 UTC+1 u=C5=BEivatel Murch napsal: > Hi Matt, > > The feerate policy change was rolled out not just with the Bitcoin Core= =20 > 30.0 release, but also backported to Bitcoin Core 29.1. According to=20 > e.g., Clark Moody=E2=80=99s dashboard, that means that over 30% of listen= ing=20 > nodes already use the lower incremental feerate (assuming they use the=20 > default value). Per a quick calculation even non-listening nodes with=20 > only eight connections should have an over 94% chance to have at least=20 > one peer that accepts and rebroadcasts such a replacement=20 > transaction=E2=80=94and rising. > > Meanwhile, very few wallets so far support creating transactions with=20 > lower feerates or implement replacements with the lower=20 > incrementalrelayfee. Presumably the wallet adoption will continue to=20 > trail the node policy adoption in this regard, exactly due to the=20 > current unreliable state. > > I am not convinced that special handling for the incrementalrelayfee is= =20 > necessary at this time, and either way, a more general approach such as= =20 > the recently proposed BIP=E2=80=AF153: SENDTEMPLATE (PR:=20 > https://github.com/bitcoin/bips/pull/1937) would feel like a bigger bang= =20 > for the buck in that regard. > > Best, > Murch > > On 2026-01-06 17:36, Matthew Hus=C3=A1k wrote: > > Hi all! > > > > Core 30.0 defaults both minrelaytxfee and incrementalrelayfee to 0.1=20 > > sat/vB now, but lots of nodes still run 1 sat/vB for=20 > > incrementalrelayfee (or other settings). > > > > *Problem 1*: You send RBF tx =E2=86=92 your node accepts =E2=86=92 peer= s reject=20 > > replacements =E2=86=92 dead end. > > *Problem 2*: You can't see what min RBF fee peers have. > > > > The obvious fix is to manually connect to peers with matching=20 > > incrementalrelayfee, which is impossible because this policy isn't=20 > > exposed over P2P. BIP133 feefilter only signals minrelaytxfee. > > > > *Proposal*: Extend feefilter with incrementalrelayfee field (parallel= =20 > > to minrelaytxfee). Peers can then filter out un-bumpable RBF invs,=20 > > reducing spam and improving propagation. > > > > *Benefits*: > > - spam protection: your node stops spamming peers with un-bumpable RBFs > > - transparency: you can see what RBF policy other nodes use, thus you= =20 > > can find miner node which you can add as manual peer > > - pure policy change, no consensus risk > > > > *WDYT guys?* > > > > Happy to prototype or draft a BIP if there's interest. > > > > Cheers, > > Matt. > > --=20 > > You received this message because you are subscribed to the Google=20 > > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > > an email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > >=20 > https://groups.google.com/d/msgid/bitcoindev/d3ddaf1c-44c9-4ebd-98fe-88e0= 3a84891en%40googlegroups.com=20 > > < > https://groups.google.com/d/msgid/bitcoindev/d3ddaf1c-44c9-4ebd-98fe-88e0= 3a84891en%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter > >. > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= a02be21c-2483-4753-b6db-4bd159e8c4e0n%40googlegroups.com. ------=_Part_838905_797874713.1767895985196 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Murch!

thanks for such quick response.
I think that we've been one of the first wallets to support = such lower fees, so we faced the initial "pain" to find peers with the lowe= r minrelaytxfee. That kinda made me feel that this has to change, because w= hen we solved the peers config (with our desired minrelaytxfee=C2=A0setting= ) we realized that many nodes (before the update) =C2=A0forgot to change th= e minincrementalfee policy and since you can't check for peer's minincremen= talfee it makes the adoption even harder, because it's almost impossible to= find peers on your own (you could sign a RBF tx bumped up to fee under 1sa= t/vb and try to send it to different peers, but thats far from ideal :-D).<= /div>

I'm not sure if lowering the defaults will ever = happen again, but I believe that you should be able to see under what condi= tions other nodes relay, so that you don't spam them with tx they don't wan= t and so that the adoption is easier.

I haven=E2= =80=99t seen BIP 153 before, so I=E2=80=99ll read it and try to understand = it. That said, I have two ideas: the simplest is to expose =C2=A0incrementa= lrelayfee=C2=A0, and the second (I=E2=80=99d love your opinion on this) is = adding the ability to configure the node to actively seek peers meeting spe= cific =C2=A0minrelaytxfee=C2=A0 and =C2=A0minincrementalfee=C2=A0 threshold= s=E2=80=94since AFAIK it currently settles for ~10 outbound nodes of any co= nfig, this would let it target at least 2 high-quality peers with those min= imums during discovery.

(or I could be totally o= ff with my ideas :-D but I hope its not that case)

Thanks!
Matt


Dne st=C5=99eda 7. = ledna 2026=C2=A0v=C2=A020:54:11 UTC+1 u=C5=BEivatel Murch napsal:
Hi Matt,

The feerate policy change was rolled out not just with the Bitcoin Core= =20
30.0 release, but also backported to Bitcoin Core 29.1. According to=20
e.g., Clark Moody=E2=80=99s dashboard, that means that over 30% of list= ening=20
nodes already use the lower incremental feerate (assuming they use the= =20
default value). Per a quick calculation even non-listening nodes with= =20
only eight connections should have an over 94% chance to have at least= =20
one peer that accepts and rebroadcasts such a replacement=20
transaction=E2=80=94and rising.

Meanwhile, very few wallets so far support creating transactions with= =20
lower feerates or implement replacements with the lower=20
incrementalrelayfee. Presumably the wallet adoption will continue to=20
trail the node policy adoption in this regard, exactly due to the=20
current unreliable state.

I am not convinced that special handling for the incrementalrelayfee is= =20
necessary at this time, and either way, a more general approach such as= =20
the recently proposed BIP=E2=80=AF153: SENDTEMPLATE (PR:=20
https://gith= ub.com/bitcoin/bips/pull/1937) would feel like a bigger bang=20
for the buck in that regard.

Best,
Murch

On 2026-01-06 17:36, Matthew Hus=C3=A1k wrote:
> Hi all!
>
> Core 30.0 defaults both minrelaytxfee and incrementalrelayfee to 0= .1=20
> sat/vB now, but lots of nodes still run 1 sat/vB for=20
> incrementalrelayfee (or other settings).
>
> *Problem 1*: You send RBF tx =E2=86=92 your node accepts =E2=86=92= peers reject=20
> replacements =E2=86=92 dead end.
> *Problem 2*: You can't see what min RBF fee peers have.
>
> The obvious fix is to manually connect to peers with matching=20
> incrementalrelayfee, which is impossible because this policy isn&#= 39;t=20
> exposed over P2P. BIP133 feefilter only signals minrelaytxfee.
>
> *Proposal*: Extend feefilter with incrementalrelayfee field (paral= lel=20
> to minrelaytxfee). Peers can then filter out un-bumpable RBF invs,= =20
> reducing spam and improving propagation.
>
> *Benefits*:
> - spam protection: your node stops spamming peers with un-bumpable= RBFs
> - transparency: you can see what RBF policy other nodes use, thus = you=20
> can find miner node which you can add as manual peer
> - pure policy change, no consensus risk
>
> *WDYT guys?*
>
> Happy to prototype or draft a BIP if there's interest.
>
> Cheers,
> Matt.
> --=20
> You received this message because you are subscribed to the Google= =20
> Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, = send=20
> an email to bitcoindev+= ...@googlegroups.com.
> To view this discussion visit=20
> https://groups.google.com/d/msgid/b= itcoindev/d3ddaf1c-44c9-4ebd-98fe-88e03a84891en%40googlegroups.com=20
> <https://groups.google.= com/d/msgid/bitcoindev/d3ddaf1c-44c9-4ebd-98fe-88e03a84891en%40googlegroups= .com?utm_medium=3Demail&utm_source=3Dfooter>.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/a02be21c-2483-4753-b6db-4bd159e8c4e0n%40googlegroups.com.
------=_Part_838905_797874713.1767895985196-- ------=_Part_838904_1433480145.1767895985196--