Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-26 📝 Original message:On Tue, Jul 26, 2022 at ...
📅 Original date posted:2022-07-26
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220726/15a41e73/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220726/15a41e73/attachment.sig>;