From: "David A. Harding" <dave@dtrt•org>
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Date: Thu, 28 Jul 2022 17:38:19 -1000 [thread overview]
Message-ID: <f889c7fc9db56ed448237c8a4091abaa@dtrt.org> (raw)
In-Reply-To: <Yt/h2Jv3m8ZsfZ8v@petertodd.org>
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).
next prev parent reply other threads:[~2022-07-29 3:38 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
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 [this message]
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=f889c7fc9db56ed448237c8a4091abaa@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/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