summaryrefslogtreecommitdiff
path: root/b0/ee546d1a371c213522819b6c0b1335f4d188ed
blob: 2d8700220d1c9d873928e8392dd3c040d4ca1c25 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
Return-Path: <dave@dtrt.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 43F46C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 03:38:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 259DF401DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 03:38:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 259DF401DD
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XXytx23YVsfH
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 03:38:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E7180401A0
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
 [IPv6:2607:fe70:0:3::d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id E7180401A0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 29 Jul 2022 03:38:22 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
 by smtpauth.rollernet.us (Postfix) with ESMTP id 52B16280006D;
 Thu, 28 Jul 2022 20:38:20 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
 [IPv6:2607:fe70:0:14::a])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate)
 by smtpauth.rollernet.us (Postfix) with ESMTPSA;
 Thu, 28 Jul 2022 20:38:19 -0700 (PDT)
MIME-Version: 1.0
Date: Thu, 28 Jul 2022 17:38:19 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Peter Todd <pete@petertodd.org>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Yt/h2Jv3m8ZsfZ8v@petertodd.org>
References: <CAGHFe1BXdTkPZn4r_KTxYoz0sqcMsV830dm5JTTFURxDezBnDQ@mail.gmail.com>
 <Yt/h2Jv3m8ZsfZ8v@petertodd.org>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <f889c7fc9db56ed448237c8a4091abaa@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
 http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 5209.62e3562b.e028d.0
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 03:38:24 -0000

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