MIME-Version: 1.0
References: <CAAUFj113g15EUXvdQG1caLBar6HakLRag6URA9Q-y52OZEmhzQ@mail.gmail.com>
In-Reply-To: <CAAUFj113g15EUXvdQG1caLBar6HakLRag6URA9Q-y52OZEmhzQ@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 21 Aug 2020 12:57:32 -0400
Message-ID: <CAB3F3DuRN2ZzubrWYE6xTF78tU2kO1=XonHf_JFdfRTHYHfgjg@mail.gmail.com>
To: DKBryant@gmail.com, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aa38d305ad662261"
Subject: Re: [bitcoin-dev] Time to lower minrelaytxfee ?
Precedence: list

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

No strong opinions but:

Denial of service attacks can become 5x cheaper.

If you don't thoroughly test
https://github.com/bitcoin/bitcoin/issues/16499 these
changes you can end up with bugs that can cause issues on p2p network.

On Fri, Aug 21, 2020 at 4:00 AM Dan Bryant via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It's been 5 years since minrealytxfee was lowered.  At the time
> bitcoin was trading for $255 and it was agreed that the fee of 5000
> sat/vkB was too high.  It was lowered to 1000 sat/vkB.  In regards to
> how much anti-DoS protection that provided, it comes out to $0.00255 /
> vkB in USD terms.  To have parity with the last reduction, we would
> need to reduce minrealytxfee to 22 sat/vKB, though an even more
> conservative reduction to 100 or 50 sat/vKB would be welcome.
>
> With the growing adoption of LN, there is a need for ultra-low-fee
> on-chain TXNs.  Having these queue and confirm overnight, or even
> waiting until the Sunday lull would still probably be welcome to many
> users.  The fact that the mempool is going empty at least every week
> indicates that miners have not reached the floor of what they are
> willing to mine.
>
> About 2 years ago there was a PR (#13922) to try to make a reduction
> from 1000 to 200 sat/vkB.  It was widely accepted but the submitter
> eventually closed it in favor of PR #13990.
>
> If minrelaytxfee is already parameterized and configurable in
> bitcoin.conf, how could it be detrimental to operation of a node to
> change the default?
>
> References:
>
> *
> https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4
> * https://github.com/bitcoin/bitcoin/pull/13922
> * https://github.com/bitcoin/bitcoin/pull/13990
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>No strong opinions but:</div><div><br></div>Denial of=
 service attacks can become 5x cheaper.<div><br></div><div>If you don&#39;t=
 thoroughly=C2=A0test=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/is=
sues/16499">https://github.com/bitcoin/bitcoin/issues/16499</a>=C2=A0these =
changes you can end up with bugs that can cause issues on p2p network.</div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Fri, Aug 21, 2020 at 4:00 AM Dan Bryant via bitcoin-dev &lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">It&#39;s been 5 years since minrealytxfee was lowered.=C2=A0 At the=
 time<br>
bitcoin was trading for $255 and it was agreed that the fee of 5000<br>
sat/vkB was too high.=C2=A0 It was lowered to 1000 sat/vkB.=C2=A0 In regard=
s to<br>
how much anti-DoS protection that provided, it comes out to $0.00255 /<br>
vkB in USD terms.=C2=A0 To have parity with the last reduction, we would<br=
>
need to reduce minrealytxfee to 22 sat/vKB, though an even more<br>
conservative reduction to 100 or 50 sat/vKB would be welcome.<br>
<br>
With the growing adoption of LN, there is a need for ultra-low-fee<br>
on-chain TXNs.=C2=A0 Having these queue and confirm overnight, or even<br>
waiting until the Sunday lull would still probably be welcome to many<br>
users.=C2=A0 The fact that the mempool is going empty at least every week<b=
r>
indicates that miners have not reached the floor of what they are<br>
willing to mine.<br>
<br>
About 2 years ago there was a PR (#13922) to try to make a reduction<br>
from 1000 to 200 sat/vkB.=C2=A0 It was widely accepted but the submitter<br=
>
eventually closed it in favor of PR #13990.<br>
<br>
If minrelaytxfee is already parameterized and configurable in<br>
bitcoin.conf, how could it be detrimental to operation of a node to<br>
change the default?<br>
<br>
References:<br>
<br>
* <a href=3D"https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505b=
a5c5df8c89210da5a6e4" rel=3D"noreferrer" target=3D"_blank">https://github.c=
om/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4</a><br>
* <a href=3D"https://github.com/bitcoin/bitcoin/pull/13922" rel=3D"noreferr=
er" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/13922</a><br>
* <a href=3D"https://github.com/bitcoin/bitcoin/pull/13990" rel=3D"noreferr=
er" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/13990</a><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>

--000000000000aa38d305ad662261--