path: root/78/b7fc76469df1350af14dbb6acfb6dc8f9913a9

Return-Path: <nadav@shesek.info>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B40ECC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 16:36:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 9D66588187
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 16:36:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7v6bCK1y5jva
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 16:36:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com
 [209.85.208.181])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 928398817F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 16:36:43 +0000 (UTC)
Received: by mail-lj1-f181.google.com with SMTP id y2so2548066ljc.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 09:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=QEOQ3uWw3CoFyw2oJbMrhnTxGuQ9JtDUGuGslN2pJ/Y=;
 b=MMUPWRFdBr7QASOU7Q6iHWo9GVZcrQ5dsNJqV46uYZLGFDPWHsgjSk86gqf5E0fOOH
 G3olVQ5KQmwdnvXejXCFIfRzSKfIPv4sINh02V3VkD+LghqQrs9nzDjNnhaJKN9gLxgU
 erEpUASfFLpz/O1blmYu0ltozT+iM4EjuZ0jw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=QEOQ3uWw3CoFyw2oJbMrhnTxGuQ9JtDUGuGslN2pJ/Y=;
 b=DudbI9PgoPVctbqKgBgX4YFAd8/0ycYjERiNRyiRPft9F14Ku7Z4ijWWZv9kz6AjO7
 7hnUfrkKhlOHz5gZW4G8iuwuaXLDsbidBOMj7buqad18UrinvSGKSa7bVtGFKwg02OHM
 95xHcEHOSdd5cSfoe5QWgrddq088BQYPCgQWJys4wlvZHEy2CIpT/fDYGpDaHaXzwAR8
 nXrljPRfnK/hHVvaPQlJhw1/U/08mdZ6iCPZtuSFu8kDV3DsXAoYGMyn2aLquzy70DOh
 F/S/zsKXj9WWynW6IwA7zxLpAYkX5XtE8hNgQ5KTsDxhuZC/1dbX9/y3kKDk6Dhg55bL
 6vHg==
X-Gm-Message-State: AOAM531k9yVnSUhIblC/pAUaM3odR/XI+HDJ56QZPdpfBtiUUN3KLlp4
 f3d57seEzQoXA9zajULAxiVDiCZD8BhgD3WRS7eOKQ==
X-Google-Smtp-Source: ABdhPJxdoDELLv605idQMzrWKq886pDOMS8KoOJdVjwpzt49u3c1emkKY7wDZ/Cx7LkvTaVq7gOWUdL59pIxhgcquos=
X-Received: by 2002:a05:651c:294:: with SMTP id
 b20mr1820464ljo.4.1598027801470; 
 Fri, 21 Aug 2020 09:36:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAAUFj113g15EUXvdQG1caLBar6HakLRag6URA9Q-y52OZEmhzQ@mail.gmail.com>
In-Reply-To: <CAAUFj113g15EUXvdQG1caLBar6HakLRag6URA9Q-y52OZEmhzQ@mail.gmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Fri, 21 Aug 2020 19:36:30 +0300
Message-ID: <CAGXD5f3=H9TinyYh122oq1x+3exTyxvvAT1m_eiNY34Nhw7bcA@mail.gmail.com>
To: DKBryant@gmail.com, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000072bb2d05ad65d7d4"
X-Mailman-Approved-At: Fri, 21 Aug 2020 16:43:00 +0000
Subject: Re: [bitcoin-dev] Time to 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, 21 Aug 2020 16:36:44 -0000

--00000000000072bb2d05ad65d7d4
Content-Type: text/plain; charset="UTF-8"

Having large portions of the network using a different minrelayfee could
make it easier to reliably get different parts of the network to accept
different conflicting transactions into their mempools, which could
potentially be used to double-spend unconfirmed non-rbf transactions with
more ease. Node operators that accept unconfirmed payments with a
minrelayfee that's higher than what other nodes/miners are typically
accepting would be at risk.

Relying on unconfirmed transactions is of course discouraged so I'm not
sure how much weight this should be given if at all, but I thought it was
at least worth bringing up.

Nadav


On Fri, Aug 21, 2020 at 11: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
>

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

<div dir=3D"ltr"><div>Having large portions of the network using a differen=
t minrelayfee could make it easier to reliably get different parts of the n=
etwork to accept different conflicting transactions into their mempools, wh=
ich could potentially be used to double-spend unconfirmed non-rbf transacti=
ons with more ease. Node operators that accept unconfirmed payments with a =
minrelayfee that&#39;s higher than what other nodes/miners are typically ac=
cepting would be at risk.<br></div><div><br></div><div>Relying on unconfirm=
ed transactions is of course discouraged so I&#39;m not sure how much weigh=
t this should be given if at all, but I thought it was at least worth bring=
ing up.</div><div><br></div><div>Nadav<br></div><br></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 21, 2020 at=
 11:00 AM Dan Bryant via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left: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>

--00000000000072bb2d05ad65d7d4--