From: Peter Todd <pete@petertodd•org>
To: aaradhya@technovanti•co.in,
Aaradhya Chauhan <chauhanansh.me@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Date: Tue, 26 Jul 2022 08:45:12 -0400 [thread overview]
Message-ID: <Yt/h2Jv3m8ZsfZ8v@petertodd.org> (raw)
In-Reply-To: <CAGHFe1BXdTkPZn4r_KTxYoz0sqcMsV830dm5JTTFURxDezBnDQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-07-26 12:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-26 8:26 Aaradhya Chauhan
2022-07-26 12:19 ` alicexbt
2022-07-26 14:27 ` Peter Todd
2022-07-26 19:14 ` alicexbt
2022-07-26 12:45 ` Peter Todd [this message]
2022-07-27 4:10 ` vjudeu
2022-07-27 11:50 ` Peter Todd
2022-07-27 12:18 ` vjudeu
2022-07-29 3:38 ` David A. Harding
2022-07-29 18:59 ` Aaradhya Chauhan
2022-07-30 7:55 ` Aaradhya Chauhan
2022-07-30 17:24 ` alicexbt
2022-08-01 10:30 ` Peter Todd
2022-08-01 13:19 ` aliashraf.btc At protonmail
2022-08-01 13:37 ` Peter Todd
2022-08-03 15:40 ` Aaradhya Chauhan
2022-08-03 17:07 ` vjudeu
2022-08-03 18:22 ` Aaradhya Chauhan
2022-08-04 1:21 ` Billy Tetrud
2022-07-30 10:20 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yt/h2Jv3m8ZsfZ8v@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=aaradhya@technovanti$(echo .)co.in \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=chauhanansh.me@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox