pull down to refresh

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:
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.
0.01 sat/vB
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.
reply
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
reply
doesn't help with scaling
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.
reply
Good joke :-)
But the idea doesn't introduce fractional sats. It's very delicate change than any node runner can do.
reply
there's no fractions of a sat possible in a tx
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.
reply
10 sats \ 2 replies \ @hynek OP 17h
Yes, but you are talking about fee rate. Fee is not in fractions of sats
  • By fee I mean sum_of_outputs-sum_of_inputs
  • By fee rate I mean fee/tx_vsize
reply
minrelaytxfee specifies fee rate, not total fee.
reply
Yes
reply
21 sats \ 1 reply \ @Scoresby 5 Jun
I'm open to the idea. The minrelaytxfee is 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.
reply
202 sats \ 0 replies \ @hynek OP 18h
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.
reply
Anything that makes blocks more predictable, eg by getting rid of need for transaction accelerators, is good with me.
reply
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?
reply
They just ignore it
reply
any suggestions how can one submit low-feerate txs manually to these pools?
reply
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.
reply
reply
I like the idea, that is a good way for scaling, we need more granularity for the fee rate.
reply
True
reply