📅 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
vjudeu at gazeta.pl [ARCHIVE] /
npub135…nssga
2023-06-07 23:12:10
in reply to nevent1q…vmsy
Author Public Key
npub1357006afyypkgz03lmq8fnuvlkyjt0rukx8rt56ck8xv396jaceqmnssgaPublished at
2023-06-07 23:12:10Event JSON
{
"id": "7d5796e525ce6358bc9a57bac418c8877f1fbf42e0e52f429b1fb4d7b2efda32",
"pubkey": "8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32",
"created_at": 1686179530,
"kind": 1,
"tags": [
[
"e",
"5d2e5e33951257609e634a8050253effbcdc80715de5454effa1da6b8afb71e8",
"",
"root"
],
[
"e",
"6003b7477e24fe965898a1bef05a2b40528ea19db616dd65c14404acab18f5f5",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-07-27\n📝 Original message:\u003e 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.\n\nJust use those settings in your node:\n\nminrelaytxfee=0.00000000\nblockmintxfee=0.00000000\ndustrelayfee=0.00000000\n\nNo 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).\n\nOn 2022-07-26 14:45:35 user Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-dev wrote:\n\u003e I know this might be a sort of repetition for a previous question, but I do\n\u003e want to know from enthusiasts in this group that while Bitcoin was trading\n\u003e at much lower price in its early days, 1 sat/vB was a good dust protection\n\u003e measure. But now, I think it's a bit high for merely a dust protection\n\u003e measure, and should be lowered slightly. Even if not, it should be lowered\n\u003e to half when prices go double than today and keeps oscillating at that\n\u003e point. As it's not a consensus rule, I think it can be done easily, just\n\u003e needing support from full node operators. I support LN but I think\n\u003e transaction affordability should remain constant in the future. If I'm okay\n\u003e to wait in a queue, I should have the option for same affordability for\n\u003e minimum fees in the future as it is today. (Like we still have posts today\n\u003e while email still exists).\n\nIf we're expecting fee revenue to be significant in the future - with constant\nbacklogs of low-fee txs - lowering the dust limit now is a good way to ensure\nthe entire ecosystem is ready to deal with those conditions. We're fairly close\nto blocks being full, so you can't argue that the dust limit provides value by\nreducing block usage. All it achieves is artificially lowering mempool usage,\nputting the Bitcoin system in a no-backlog state that's quite unlike how we're\nexpecting Bitcoin to operate in the future. And indeed, the state Bitcoin can\noperate in at any moment if there is a demand spike.\n\nSo I'd suggest removing the fixed dust limit entirely and relying purely on the\nmempool size limit to determine what is or is not dust.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "3bb63bed8078d9dab470d615aefc05e0da6cbfd7780c1b8629089f7f2a9e8b2a1b8461832c024359308ff1250fd134dbf0c4e110b5a14ea0ad8319bebc1787a0"
}