MIME-Version: 1.0
References: <CAGHFe1BXdTkPZn4r_KTxYoz0sqcMsV830dm5JTTFURxDezBnDQ@mail.gmail.com>
 <Yt/h2Jv3m8ZsfZ8v@petertodd.org> <f889c7fc9db56ed448237c8a4091abaa@dtrt.org>
In-Reply-To: <f889c7fc9db56ed448237c8a4091abaa@dtrt.org>
Reply-To: aaradhya@technovanti.co.in
From: Aaradhya Chauhan <chauhanansh.me@gmail.com>
Date: Sat, 30 Jul 2022 00:29:31 +0530
Message-ID: <CAGHFe1BxFX_v3FKTHMTbV+WARX5MjuJ6Y7=NdMc-wVYZDQUa7Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000b85b8805e4f640b7"
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Precedence: list

--000000000000b85b8805e4f640b7
Content-Type: text/plain; charset="UTF-8"

I think you misunderstood what I said. I did not say that it should be done
now, for the obvious reasons that the miners won't be doing any good by
such measures. But I am talking about when the price of BTC escalates to a
point when 1sat/vB becomes expensive as a dust limit. If the price
oscillates at that point and above, it would actually create the same
incentives as it is today. All I imply is to maintain the affordability of
the minimum possible fee if one is ready to wait.

On Fri, 29 Jul 2022 at 9:08 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000b85b8805e4f640b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><span style=3D"word-spacing:1px;border-color:rgb(49,49,49);color:rgb(4=
9,49,49)">I think you misunderstood what I said. I did not say that it shou=
ld be done now, for the obvious=C2=A0reasons that the miners won&#39;t be d=
oing any good by such measures. But I am talking about when the price of BT=
C escalates to a point when 1sat/vB becomes expensive as a dust limit. If t=
he price oscillates at that point=C2=A0and above, it would actually create =
the same incentives as it is today. All I imply is to maintain the affordab=
ility of the minimum possible fee if one is ready to wait.</span><br></div>=
<div dir=3D"auto"><span style=3D"word-spacing:1px;border-color:rgb(49,49,49=
);color:rgb(49,49,49)"><br></span></div><div><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Fri, 29 Jul 2022 at 9:08 AM David A. =
Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(=
204,204,204)">On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:<br>
&gt; On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via <br>
&gt; bitcoin-dev wrote:<br>
&gt;&gt; [...] in its early days, 1 sat/vB was a good dust protection<br>
&gt;&gt; measure. But now, I think it&#39;s a bit high [...] I think it can=
 be done <br>
&gt;&gt; easily [...]<br>
&gt; <br>
&gt; [...] lowering the dust limit now is a good way to ensure<br>
&gt; the entire ecosystem is ready to deal with those conditions.<br>
<br>
I don&#39;t have anything new to add to the conversation at this time, but =
I <br>
did want to suggest a clarification and summarize some previous <br>
discussion that might be useful.<br>
<br>
I think the phrasing by Aaradhya Chauhan and Peter Todd above are <br>
conflating the minimum output amount policy (&quot;dust limit&quot;) with t=
he <br>
minimum transaction relay feerate policy (&quot;min tx relay fee&quot;).=C2=
=A0 Any <br>
transaction with an output amount below a node&#39;s configured dust limit =
<br>
(a few hundred sat by default) will not be relayed by that node no <br>
matter how high of a feerate it pays.=C2=A0 Any transaction with feerate <b=
r>
below a nodes&#39;s minimum relay feerate (1 sat/vbyte by default) will not=
 <br>
be relayed by that node even if the node has unused space in its mempool <b=
r>
and peers that use BIP133 feefilters to advertise that they would accept <b=
r>
low feerates.<br>
<br>
Removing the dust limit was discussed extensively a year ago[1] with <br>
additional follow-up discussion about eight months ago.[2]<br>
<br>
Lowering the minimum relay feerate was seriously proposed in a patch to <br=
>
Bitcoin Core four years ago[3] with additional related PRs being opened <br=
>
to ease the change.=C2=A0 Not all of the related PRs have been merged yet, =
<br>
and the original PR was closed.=C2=A0 I can&#39;t easily find some of the <=
br>
discussions I remember related to that change, but IIRC part of the <br>
challenge was that lower minimum relay fees reduce the cost of a variety <b=
r>
of DoS attacks which could impact BIP152 compact blocks and erlay <br>
efficiency, could worsen transaction pinning, may increase IBD time due <br=
>
to more block chain data, and have other adverse effects.=C2=A0 Additionall=
y, <br>
we&#39;ve found in the past that some people who build systems that take <b=
r>
advantage of low feerates become upset when feerates rise, sometimes <br>
creating problems even for people who prepared for eventual feerate <br>
rises.<br>
<br>
Compared to the complexity of lowering the minimum feerate, the <br>
challenges of preventing denial/degregation-of-service attacks, and <br>
dealing with a fragmented userbase, the economic benefit of reducing the <b=
r>
feerates for the bottom of the mempool seems small---if we lower min <br>
feerates to 1/10th their current values and that results in the <br>
equivalent of an extra 10 blocks of transactions getting mined a day, <br>
then users save a total of 0.09 BTC (~$1,800 USD) per day and miners <br>
earn an extra 0.01 BTC ($200 USD) per day (assuming all other things <br>
remain equal).[4]<br>
<br>
-Dave<br>
<br>
[1] <br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Aug=
ust/019307.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2021-August/019307.html</a><br>
[2] <br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Dec=
ember/019635.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-December/019635.html</a><br>
[3] <a href=3D"https://github.com/bitcoin/bitcoin/pull/13922" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/13922</a><b=
r>
[4] The current min relay fee is 1 sat/vbyte.=C2=A0 There are ~1 million <b=
r>
vbytes in a block that can be allocated to regular transactions.=C2=A0 Ten =
<br>
blocks at the current min relay fee would pay (10 * 1e6 / 1e8 =3D 0.1 BTC) =
<br>
in fees.=C2=A0 Ten blocks at 1/10 sat/vbyte would thus pay 0.01 BTC in fees=
, <br>
which is $200 USD @ $20k/BTC.=C2=A0 Thus users would save (0.1 - 0.01 =3D 0=
.09 <br>
BTC =3D $1,800 USD @ $20k/BTC).<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000b85b8805e4f640b7--