Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5772BC002D for ; 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 ; 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 ; 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 ; Fri, 29 Jul 2022 18:59:43 +0000 (UTC) Received: by mail-io1-xd34.google.com with SMTP id n138so4304929iod.4 for ; 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: In-Reply-To: Reply-To: aaradhya@technovanti.co.in From: Aaradhya Chauhan Date: Sat, 30 Jul 2022 00:29:31 +0530 Message-ID: To: Bitcoin Protocol Discussion , "David A. Harding" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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'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.
=

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 t= he
minimum transaction relay feerate policy ("min tx relay fee").=C2= =A0 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.=C2=A0 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.=C2=A0 Not all of the related PRs have been merged yet, =
and the original PR was closed.=C2=A0 I can't easily find some of the <= br> 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.=C2=A0 Additionall= y,
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.linuxfo= undation.org/pipermail/bitcoin-dev/2021-August/019307.html
[2]
https://lists.linux= foundation.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.=C2=A0 There are ~1 million vbytes in a block that can be allocated to regular transactions.=C2=A0 Ten =
blocks at the current min relay fee would pay (10 * 1e6 / 1e8 =3D 0.1 BTC) =
in fees.=C2=A0 Ten blocks at 1/10 sat/vbyte would thus pay 0.01 BTC in fees= ,
which is $200 USD @ $20k/BTC.=C2=A0 Thus users would save (0.1 - 0.01 =3D 0= .09
BTC =3D $1,800 USD @ $20k/BTC).
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000b85b8805e4f640b7--