I think you misunderstood what I said. I did not say that it should be done now, for the obvious reasons that the miners won't be doing any good by such measures. But I am talking about when the price of BTC escalates to a point when 1sat/vB becomes expensive as a dust limit. If the price oscillates at that point and above, it would actually create the same incentives as it is today. All I imply is to maintain the affordability of the minimum possible fee if one is ready to wait. On Fri, 29 Jul 2022 at 9:08 AM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote: > > On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via > > bitcoin-dev wrote: > >> [...] in its early days, 1 sat/vB was a good dust protection > >> measure. But now, I think it's a bit high [...] I think it can be done > >> easily [...] > > > > [...] lowering the dust limit now is a good way to ensure > > the entire ecosystem is ready to deal with those conditions. > > I don't have anything new to add to the conversation at this time, but I > did want to suggest a clarification and summarize some previous > discussion that might be useful. > > I think the phrasing by Aaradhya Chauhan and Peter Todd above are > conflating the minimum output amount policy ("dust limit") with the > minimum transaction relay feerate policy ("min tx relay fee"). Any > transaction with an output amount below a node's configured dust limit > (a few hundred sat by default) will not be relayed by that node no > matter how high of a feerate it pays. Any transaction with feerate > below a nodes's minimum relay feerate (1 sat/vbyte by default) will not > be relayed by that node even if the node has unused space in its mempool > and peers that use BIP133 feefilters to advertise that they would accept > low feerates. > > Removing the dust limit was discussed extensively a year ago[1] with > additional follow-up discussion about eight months ago.[2] > > Lowering the minimum relay feerate was seriously proposed in a patch to > Bitcoin Core four years ago[3] with additional related PRs being opened > to ease the change. Not all of the related PRs have been merged yet, > and the original PR was closed. I can't easily find some of the > discussions I remember related to that change, but IIRC part of the > challenge was that lower minimum relay fees reduce the cost of a variety > of DoS attacks which could impact BIP152 compact blocks and erlay > efficiency, could worsen transaction pinning, may increase IBD time due > to more block chain data, and have other adverse effects. Additionally, > we've found in the past that some people who build systems that take > advantage of low feerates become upset when feerates rise, sometimes > creating problems even for people who prepared for eventual feerate > rises. > > Compared to the complexity of lowering the minimum feerate, the > challenges of preventing denial/degregation-of-service attacks, and > dealing with a fragmented userbase, the economic benefit of reducing the > feerates for the bottom of the mempool seems small---if we lower min > feerates to 1/10th their current values and that results in the > equivalent of an extra 10 blocks of transactions getting mined a day, > then users save a total of 0.09 BTC (~$1,800 USD) per day and miners > earn an extra 0.01 BTC ($200 USD) per day (assuming all other things > remain equal).[4] > > -Dave > > [1] > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html > [2] > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019635.html > [3] https://github.com/bitcoin/bitcoin/pull/13922 > [4] The current min relay fee is 1 sat/vbyte. There are ~1 million > vbytes in a block that can be allocated to regular transactions. Ten > blocks at the current min relay fee would pay (10 * 1e6 / 1e8 = 0.1 BTC) > in fees. Ten blocks at 1/10 sat/vbyte would thus pay 0.01 BTC in fees, > which is $200 USD @ $20k/BTC. Thus users would save (0.1 - 0.01 = 0.09 > BTC = $1,800 USD @ $20k/BTC). > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >