path: root/fd/587c2fb3e7e7023dc2624c575ead451da7d4f5

Return-Path: <chauhanansh.me@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4D046C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Jul 2022 07:56:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 150DA8402B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Jul 2022 07:56:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 150DA8402B
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=ihnFCi4M
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0Mg6L-bxi2GL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Jul 2022 07:56:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 716A383E5A
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com
 [IPv6:2607:f8b0:4864:20::12a])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 716A383E5A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Jul 2022 07:56:07 +0000 (UTC)
Received: by mail-il1-x12a.google.com with SMTP id 1so3377224ill.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Jul 2022 00:56:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:reply-to:from:date:message-id
 :subject:to; bh=qf4zpdMac1vvMr+o2dibeSjsyJzUGDeuHYMiDoOS0Vw=;
 b=ihnFCi4M1kMPTxKh+b3EgdQrcva2JY44gqIgUFeIyWARH9s6G77TTyaZUkU77FdPFr
 Q6I+kh13pmooPwq0KTN9/mss0xatBzHD6NYDMMSWbx05F3vfE6Eu2NG48mqU0bDhl6k4
 Cn1NRA7dG5ZbhdPt6ftDLNbCvYyiR2bbQW7TXAD+iowAvT5lgd/HmqemWrT+ES5Cbaib
 muwiAwnDU0BHN0SWZCExWqjk7Qt/3N8AiW545Ux9E7v1wa1jNak7huQ0NoZKmmcadv+C
 xYrlC7pkLhHbTJPWGnE14Tf27UoquNTpJW8hZTxIwjDQxhBU7LvRKQh+LCzGXflMepwn
 KM8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:reply-to
 :from:date:message-id:subject:to;
 bh=qf4zpdMac1vvMr+o2dibeSjsyJzUGDeuHYMiDoOS0Vw=;
 b=xk97RY6nvSs7JCPNPSxPFtR114UTih2vV70dvzGxTibiaWkcB+wy7AB3ebaHdprq5p
 bvF0NdMc5EbzNkHdkTTZKDVom49JTHs4E3nLJV9AYKeBmM1KHp2ZPGHIq0HWdl2W+jaW
 ZNAgNGX4KJuhL2sMjVI61K9HmVQfxpeK8qLSevA/P45DBrgko3ofdzzmhlCb6rpPKms7
 OKJkWqDLSDBVckTNoipgF+UMWgZF7DvcENOjjsNLLhkUDG1NvjbNLdIA/JqAsILPQHso
 3C8iSP8DkGgmt0mYsZXjsrX+666cZOBR4AdxSDC1VgcBtR2r+KLFFaO0cWOgAYYtY2jq
 2NVg==
X-Gm-Message-State: AJIora+eibPxZ7Q6FMxei0J+5QWKHd3H5O6bm5rBuYI4Z/rHWlsbN6Wq
 ffQBqdAGw+gv1DLb4OhAlIkm5Gv4Bj7MbXjGt1nDUHx3Ew==
X-Google-Smtp-Source: AGRyM1vjWYDa1wQQ0sNGauPteSbXb0ZWiLMWAX/peJ++vRjeXzyU4vSLed3yYxsmh05Q3WezVTZ23jW42JSAFOmrMqY=
X-Received: by 2002:a05:6e02:1647:b0:2dc:fe4c:7d40 with SMTP id
 v7-20020a056e02164700b002dcfe4c7d40mr2757853ilu.94.1659167766375; Sat, 30 Jul
 2022 00:56:06 -0700 (PDT)
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 13:25:55 +0530
Message-ID: <CAGHFe1C-u7DbTtg0dz+p8Moh=FbFN5dKZow5HgtMpxcVyS2ZdA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005674fd05e501194c"
X-Mailman-Approved-At: Sat, 30 Jul 2022 09:12:59 +0000
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jul 2022 07:56:09 -0000

--0000000000005674fd05e501194c
Content-Type: text/plain; charset="UTF-8"

I'm not suggesting to initiate it anytime soon. But suppose, let's take a
situation where Bitcoin reaches and oscillates above 200k to 500k USD, then
1 sat/vB could be equivalent to 10 sat/vB of today, hampering the "dust
requirement" (ignoring inflation). I discussed this on the Bitcoin
subreddit and some suggested that the developers, in the future, have to
just change the "default minimum relay tx fee" from 1000 today to 500 at
that time. Obviously it's gonna be a little above 500, if we count
inflation. That would simply equate to the current situation. Do you think
that would be a problem?

On Fri, 29 Jul 2022 at 09:08, 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
>

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

<div dir=3D"ltr">I&#39;m not suggesting to initiate it anytime=C2=A0soon. B=
ut suppose, let&#39;s take a situation where Bitcoin reaches and oscillates=
 above 200k to 500k USD, then 1 sat/vB could be equivalent to 10 sat/vB of =
today, hampering the &quot;dust requirement&quot; (ignoring inflation). I d=
iscussed this on the Bitcoin subreddit and some suggested that the develope=
rs, in the future, have to just change the &quot;default minimum relay tx f=
ee&quot; from 1000 today to 500 at that time. Obviously it&#39;s gonna be a=
 little above 500, if we count inflation. That would simply equate to the c=
urrent situation. Do you think that would be a problem?<br></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 29 Jul 2=
022 at 09:08, David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex">On 2022-07-26 02:45, Peter Todd via bi=
tcoin-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>

--0000000000005674fd05e501194c--