path: root/e2/3a94dc2e0867f551759c80e351b3897c7bdd44

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 5772BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 18:59:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 31CEB84175
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 18:59:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 31CEB84175
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=cVbRus2v
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 2kq3qIEwfhjb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 18:59:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E61D584173
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com
 [IPv6:2607:f8b0:4864:20::d34])
 by smtp1.osuosl.org (Postfix) with ESMTPS id E61D584173
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 18:59:43 +0000 (UTC)
Received: by mail-io1-xd34.google.com with SMTP id n138so4304929iod.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 11:59:43 -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=tAWlVi9s6xdYiD3YpzqmTJCDOWMeG/GjfyZZO9ovH5E=;
 b=cVbRus2vGIypBnliHw/PZMnXAS+b2vkWOLFYyXbCz2jUodUHaKpVH6IG/pgTE+OpN2
 5vgz3tnXza0h7EMIewg6wn9JfVFiQ5DXDSfxl3iw1FGwOeM0pldtaBNhDp/NLrESRznh
 j39X98cObGlqkiqs4WOmtEBMcdn8jg/L1xWOgi8E2I3lW0kGHM/V2hm2rSabKmIlZJtL
 4Fne2wiedHBJi+vsJJ+ZAmvcEZrqRBOLQLLuFC0GT9VCvmqOxM7/UiILRp+IaAF8j2X2
 s6RVtQmSg+bPi1IOaYTKAVTKRjK40F7RpmcPaWPX64hECos1xQ6ddghb3feV2bsn9Nu3
 Xk2g==
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=tAWlVi9s6xdYiD3YpzqmTJCDOWMeG/GjfyZZO9ovH5E=;
 b=7LAt73q56D4FaU6q/UN0GhUladh3k2wQzkwHj97wYoQ54LRnAJsMlQwzeQMCibZHxN
 eUiqFGLrzOZ0J9Q+ejmyY6eVWgitznppdRonU1tZeKG3o2zcBcD5R6hGq8R55koo+tSr
 f63T7w54Jm6G+4PqT0LGJXOF+YjLtVAWpzF9hOFcig+LVsFJgsTOvTlYanx2DFTejhoy
 PUdIe6K6HsMrm3NLvKlHSfVVr7JwUljN5nbcP4LInK33bE8DM590aNQXCIl3wxHKAP28
 19+yOT3I0ZHVJ+XSejo7oQPljp3h49TcRvFsIKXHIhiJAFEnR4mO+ouWHNq92YKQcTpR
 TyiQ==
X-Gm-Message-State: AJIora/iEZlDNbYWWte55zfzcO2LKOesMlkBlG3RRmMrHHdgdoxS6jwD
 V7asAExctvMIJ+KFUqNntps12jyCQ++jALglOdzPVBk=
X-Google-Smtp-Source: AGRyM1t5vjE9OIpkndVJVZmt9FlQ8GI0FZRj76lu5M18VOXZWUByJxpLoBvvCFDmylBlj9qU1orOXHq+syaRi+XpiPM=
X-Received: by 2002:a05:6638:12c6:b0:341:999d:6ea7 with SMTP id
 v6-20020a05663812c600b00341999d6ea7mr1972427jas.267.1659121182463; Fri, 29
 Jul 2022 11:59:42 -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 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"
X-Mailman-Approved-At: Fri, 29 Jul 2022 19:06:04 +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: Fri, 29 Jul 2022 18:59:45 -0000

--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--