The minrelaytxfee parameter defines the minimum transaction fee that a node is willing to relay to other nodes on the network. Typically set to 0.00001 BTC/kvB, which translates to a minimum of 1 sat/vB. This value determines the threshold for transaction propagation. To bump a transaction, the fee rate should be increased by at least 1 sat/vB.
But what is the purpose of this parameter? Is a transaction with a low fee truly spam? Even a transaction with a fee of 1 sat is better than nothing in case of non-full blocks. The 1 sat/vB threshold is arbitrary anyway. Simple transaction can cost around 140 sats at this rate. Given that 140 sats have significantly more value today than in the past, I think it might worth reevaluating this threshold.
Lowering the relay fee could open up new possibilities and improve incentives for optimization. Currently, mining pools often include transactions with fees lower than 1 sat/vB in their blocks. Few examples just from today:
- https://mempool.space/tx/47be054cb5bf65387e972216c2e403040b50bc7449685c990ffeddbd0cc0d87f
- https://mempool.space/tx/c8fb770b81574cc51e7dbb5e9ab46aafd3ddc745346f1a0e4e3fc5fba6d477c2
- https://mempool.space/tx/c6eb5e7e3ad4f4d4525b17a4087be0d63d64c1c52e3dec8f8f9b540d71f48838
However, since nodes ignore these transactions, users are forced to go directly to miners, which hampers predictability.
Therefore I'm considering reducing the minrelaytxfee value by two orders of magnitude to 0.0000001, (0.01 sat/vB). In theory, this would allow me to broadcast transactions with total fees of 1-2 sats, rather than the current 140 sats.
What are your thoughts on this?
Funnily enough, this is a real scaling thing unlike most of the scaling fud you hear about... the minimum spend inclusive of fees is the only bottleneck anywhere in sight for retail users, not throughput.
I think it gets a little trickier than this because there's no fractions of a sat possible in a tx, so needs to deal with whole sats. Should be able to just allow 1 sat (or 10? 100?) per tx.
This doesn't help with scaling. But it could bring more granularity to fee market and keep it public.
I don't see the problem with the fraction. You still send whole amounts of sats. Fee rate is only a tool to compare the absolute fees. So in the example above, you could relay simple transaction (141 vB) for 2 sat → 0,014 sat/vB
Neither does anything else, thats the joke... but it does move the needle on people who are the subject of scaling virtue signals by reducing overall fee requirements.
I'm not in-depthly familiar at the implementation level to know if the fractional sats would work or not, I just think not, not a consensus thing but rather because I think a PR would be a little more complicated than changing the denominator.
Good joke :-)
But the idea doesn't introduce fractional sats. It's very delicate change than any node runner can do.
It is possible and happens all the time, as there is no txfee field in tx data structure, it's just (sum_of_inputs - sum_of_outputs) / tx_vsize.
Yes, but you are talking about fee rate. Fee is not in fractions of sats
feeI meansum_of_outputs-sum_of_inputsfee rateI meanfee/tx_vsizeminrelaytxfeespecifies fee rate, not total fee.Yes
I'm open to the idea. The
minrelaytxfeeis a subsidy to miners, so I could see criticism from people who think Bitcoin will have a security budget problem. Hash rate keeps climbing, though.We bitcoiners like free markets, right? Let's do it.
Exactly. And this could even help with the security budget because on-chain might become even more accessible. It's kind of free money for miners actually.
Anything that makes blocks more predictable, eg by getting rid of need for transaction accelerators, is good with me.
How do your peers react if you rely them transaction with a fee lower than 1? Do they disconnect from you or do they just ignore the transaction?
They just ignore it
any suggestions how can one submit low-feerate txs manually to these pools?
IIRC this has been actively regression tested since 2019 (bitcoin/bitcoin#16507) on Bitcoin Core - it should be valid config, and I think that you can just do this.
+1
I like the idea, that is a good way for scaling, we need more granularity for the fee rate.
True