> So I'd suggest removing the fixed dust limit entirely and relying purely on > the mempool size limit to determine what is or is not dust.
Just use those settings in your node: minrelaytxfee=0.00000000 blockmintxfee=0.00000000 dustrelayfee=0.00000000 No changes in source code are needed, nodes can change their limits without asking anyone. And if some node is a miner, then it can be enforced. But if not, then still, free transactions are useful for communication (if more of them will be accepted, then we will switch to negative fee transactions with proper sighashes, then it will be very unlikely that miners will voluntarily add coins, so it will remain useful for communication). On 2022-07-26 14:45:35 user Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-dev > wrote: > I know this might be a sort of repetition for a previous question, but I do > want to know from enthusiasts in this group that while Bitcoin was trading > at much lower price in its early days, 1 sat/vB was a good dust protection > measure. But now, I think it's a bit high for merely a dust protection > measure, and should be lowered slightly. Even if not, it should be lowered > to half when prices go double than today and keeps oscillating at that > point. As it's not a consensus rule, I think it can be done easily, just > needing support from full node operators. I support LN but I think > transaction affordability should remain constant in the future. If I'm okay > to wait in a queue, I should have the option for same affordability for > minimum fees in the future as it is today. (Like we still have posts today > while email still exists). If we're expecting fee revenue to be significant in the future - with constant backlogs of low-fee txs - lowering the dust limit now is a good way to ensure the entire ecosystem is ready to deal with those conditions. We're fairly close to blocks being full, so you can't argue that the dust limit provides value by reducing block usage. All it achieves is artificially lowering mempool usage, putting the Bitcoin system in a no-backlog state that's quite unlike how we're expecting Bitcoin to operate in the future. And indeed, the state Bitcoin can operate in at any moment if there is a demand spike. So I'd suggest removing the fixed dust limit entirely and relying purely on the mempool size limit to determine what is or is not dust. -- https://petertodd.org 'peter'[:-1]@petertodd.org _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
