Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte

Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte
2025-01-31 12:54 ` Sjors Provoost
  
From: Greg Tonoski @ 2025-01-31  8:49 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

The minrelaytxfee default value of 1000/kvB (1 sat/vbyte) has been set
in Bitcoin nodes since 2013 or earlier. In 2013, 1000 sats were priced
at $0.01, today it is about 100 times more. Wouldn't you like to
consider adjusting your node configuration and lower the hurdle,
perhaps? I would suggest setting minrelaytxfee=0.00000001 (which
translates to 0.001 sat/vbyte) as a rule of thumb. The value could be
set in a bitcoin.conf file. There is negligible number of such
reconfigured nodes relaying transactions with fee-rates below 1
sat/vbyte currently.

There is the intention to unblock transactions with fee-rate below 1
sat/vbyte in Bitcoin. Probably consolidation and multisig types of
transactions would benefit the most.

-- 
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/CAMHHROxVo_7ZRFy%2Bnq_2YzyeYNO1ijR_r7d89bmBWv4f4wb9%3Dg%40mail.gmail.com.


 permalink raw reply	[|nested]
2025-01-31  8:49 [bitcoindev] Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte Greg Tonoski

  2025-01-31 13:43   ` Greg Tonoski
  
From: Sjors Provoost @ 2025-01-31 12:54 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

If you want to go this route, you may also want to set -incrementalrelayfee. That way you can bump 0.001 ṩ/vB to 0.002 ṩ/vB, otherwise you'll have to go straight to 1.001 ṩ/vB.

In addition, you would need to convince at least one miner to configure a matching -blockmintxfee, otherwise these low fee transactions remain stuck in your mempool until expiration (or CPFP).

Some background: https://bitcoin.stackexchange.com/a/120782/4948

A downside to consider is that it makes any potential mempool DoS attack 1000x cheaper*, but I don't know if there are any to worry about.

Comparison with historical minimum fee rates can be tricky, especially because the lightning network wasn't around yet. There's now an increased incentive to knock out a full node if it's connected to a lightning node. So even if there's no vulnerability to attack today, it's probably good to keep fees somewhat high to ensure new attacks are expensive.

- Sjors

* = assuming the attack scales linear with the amount of transaction data, and not e.g. quadratic or exponential

> Op 31 jan 2025, om 09:49 heeft Greg Tonoski <gregtonoski@gmail•com> het volgende geschreven:
> 
> The minrelaytxfee default value of 1000/kvB (1 sat/vbyte) has been set
> in Bitcoin nodes since 2013 or earlier. In 2013, 1000 sats were priced
> at $0.01, today it is about 100 times more. Wouldn't you like to
> consider adjusting your node configuration and lower the hurdle,
> perhaps? I would suggest setting minrelaytxfee=0.00000001 (which
> translates to 0.001 sat/vbyte) as a rule of thumb. The value could be
> set in a bitcoin.conf file. There is negligible number of such
> reconfigured nodes relaying transactions with fee-rates below 1
> sat/vbyte currently.
> 
> There is the intention to unblock transactions with fee-rate below 1
> sat/vbyte in Bitcoin. Probably consolidation and multisig types of
> transactions would benefit the most.

-- 
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/A8F96312-613D-4090-B6C9-0A4C41418986%40sprovoost.nl.


 permalink raw reply	[|nested]
2025-01-31 12:54 ` Sjors Provoost

  2025-01-31 14:40     ` Sjors Provoost
  2025-02-03 19:42     ` Murch
  
From: Greg Tonoski @ 2025-01-31 13:43 UTC (permalink / raw)
  To: Sjors Provoost;  Bitcoin Development Mailing List

I agree that -incrementalrelayfee=0 (or whatever suits a node runner)
would logically supplement the minrelaytxfee=0.00000001.

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.

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.

On Fri, Jan 31, 2025 at 1:59 PM Sjors Provoost <sjors@sprovoost•nl> wrote:
>
> If you want to go this route, you may also want to set -incrementalrelayfee. That way you can bump 0.001 ṩ/vB to 0.002 ṩ/vB, otherwise you'll have to go straight to 1.001 ṩ/vB.
>
> In addition, you would need to convince at least one miner to configure a matching -blockmintxfee, otherwise these low fee transactions remain stuck in your mempool until expiration (or CPFP).
>
> Some background: https://bitcoin.stackexchange.com/a/120782/4948
>
> A downside to consider is that it makes any potential mempool DoS attack 1000x cheaper*, but I don't know if there are any to worry about.
>
> Comparison with historical minimum fee rates can be tricky, especially because the lightning network wasn't around yet. There's now an increased incentive to knock out a full node if it's connected to a lightning node. So even if there's no vulnerability to attack today, it's probably good to keep fees somewhat high to ensure new attacks are expensive.
>
> - Sjors
>
> * = assuming the attack scales linear with the amount of transaction data, and not e.g. quadratic or exponential
>
> > Op 31 jan 2025, om 09:49 heeft Greg Tonoski <gregtonoski@gmail•com> het volgende geschreven:
> >
> > The minrelaytxfee default value of 1000/kvB (1 sat/vbyte) has been set
> > in Bitcoin nodes since 2013 or earlier. In 2013, 1000 sats were priced
> > at $0.01, today it is about 100 times more. Wouldn't you like to
> > consider adjusting your node configuration and lower the hurdle,
> > perhaps? I would suggest setting minrelaytxfee=0.00000001 (which
> > translates to 0.001 sat/vbyte) as a rule of thumb. The value could be
> > set in a bitcoin.conf file. There is negligible number of such
> > reconfigured nodes relaying transactions with fee-rates below 1
> > sat/vbyte currently.
> >
> > There is the intention to unblock transactions with fee-rate below 1
> > sat/vbyte in Bitcoin. Probably consolidation and multisig types of
> > transactions would benefit the most.
>
> --
> 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/A8F96312-613D-4090-B6C9-0A4C41418986%40sprovoost.nl.

-- 
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/CAMHHROwmm0_%2BAOcBHj6Qrf07HWxzK0%3Dioeqf6nRf1kAqQhf5wg%40mail.gmail.com.


 permalink raw reply	[|nested]
2025-01-31 13:43   ` Greg Tonoski

  2025-01-31 15:13       ` Sjors Provoost
  2025-02-03 19:42     ` Murch
  
From: Sjors Provoost @ 2025-01-31 14:40 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


> 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.

It seems more likely that they used the prioritisetransaction RPC [0] in order to
include only those 0 fee transaction that they were paid for (via lightning, creditcard).

> 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.

I could quote Donald Rumsfeld, but instead I'll point out that you're
forgetting about bandwidth, memory[1] and CPU usage.

- Sjors

[0] https://bitcoincore.org/en/doc/28.0.0/rpc/mining/prioritisetransaction/
[1] e.g. https://bitcoincore.org/en/2024/10/08/disclose-large-inv-to-send/ 

-- 
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/2F74C8F3-F1E1-4714-A4B4-03169E7CF597%40sprovoost.nl.


 permalink raw reply	[|nested]
2025-01-31 14:40     ` Sjors Provoost

  
From: Sjors Provoost @ 2025-01-31 15:13 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

> 
> I could quote Donald Rumsfeld, but instead I'll point out that you're
> forgetting about bandwidth, memory[1] and CPU usage.

Memory is of course accounted for with -maxmempool. I meant to say:

bandwidth and CPU usage. [1]

> [1] e.g. https://bitcoincore.org/en/2024/10/08/disclose-large-inv-to-send/

-- 
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/C115EBBC-3AD9-446F-A778-F10E34E1A22D%40sprovoost.nl.


 permalink raw reply	[|nested]
2025-01-31 13:43   ` Greg Tonoski
  2025-01-31 14:40     ` Sjors Provoost

  
From: Murch @ 2025-02-03 19:42 UTC ( / )
  To: bitcoindev




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.