vjudeu at gazeta.pl [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-27 📝 Original message:> So I'd suggest removing ...
📅 Original date posted:2022-07-27
📝 Original message:> 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 at 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 at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:> 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 at 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 at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev