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
136
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4C012C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jul 2022 04:10:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 0288D40193
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jul 2022 04:10:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0288D40193
Authentication-Results: smtp2.osuosl.org;
dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
header.a=rsa-sha256 header.s=2013 header.b=Re+9JreK
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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,
SPF_HELO_NONE=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 kPCvL05w2Jkm
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jul 2022 04:10:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 544374011C
Received: from smtpo78.poczta.onet.pl (smtpo78.poczta.onet.pl [141.105.16.28])
by smtp2.osuosl.org (Postfix) with ESMTPS id 544374011C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jul 2022 04:10:08 +0000 (UTC)
Received: from pmq2v.m5r2.onet (pmq2v.m5r2.onet [10.174.32.68])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4Lt0fw6yGgz2K4cqR;
Wed, 27 Jul 2022 06:10:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1658895001; bh=BMnpW7izgXmGtjWZh4uArAtC965ClGox3NxEfsoY37Q=;
h=From:To:In-Reply-To:Date:Subject:From;
b=Re+9JreKpg/i0iMsAVFJKHXDM4HpD8G60EYBuyuGrMSupBHGqn6kRlcfzihAz1LRW
wEWvoykFQbxi0zoL6oD96gi3wWMh8pmdooh4LT5CYcyelxUjhDN1xhXzfAUmtTIL2a
XMgrnEpGr5FEiDVNBncNv9w9x/tY4zUT2FsPnipU=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.233.101] by pmq2v.m5r2.onet via HTTP id ;
Wed, 27 Jul 2022 06:10:00 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: "Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
aaradhya@technovanti.co.in, Aaradhya Chauhan <chauhanansh.me@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Yt/h2Jv3m8ZsfZ8v@petertodd.org>
Date: Wed, 27 Jul 2022 06:10:00 +0200
Message-Id: <165817500-9cd6c638a6ebf3036340d99291955e18@pmq2v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.233.101;PL;3
X-Mailman-Approved-At: Wed, 27 Jul 2022 11:17:43 +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: Wed, 27 Jul 2022 04:10:11 -0000
> So I'd suggest removing the fixed dust limit entirely and relying purely =
on the mempool size limit to determine what is or is not dust.
Just use those settings in your node:
minrelaytxfee=3D0.00000000
blockmintxfee=3D0.00000000
dustrelayfee=3D0.00000000
No changes in source code are needed, nodes can change their limits without=
asking anyone. And if some node is a miner, then it can be enforced. But i=
f not, then still, free transactions are useful for communication (if more =
of them will be accepted, then we will switch to negative fee transactions =
with proper sighashes, then it will be very unlikely that miners will volun=
tarily add coins, so it will remain useful for communication).
On 2022-07-26 14:45:35 user Peter Todd via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
> On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-de=
v wrote:
> I know this might be a sort of repetition for a previous question, but I =
do
> want to know from enthusiasts in this group that while Bitcoin was trading
> at much lower price in its early days, 1 sat/vB was a good dust protection
> measure. But now, I think it's a bit high for merely a dust protection
> measure, and should be lowered slightly. Even if not, it should be lowered
> to half when prices go double than today and keeps oscillating at that
> point. As it's not a consensus rule, I think it can be done easily, just
> needing support from full node operators. I support LN but I think
> transaction affordability should remain constant in the future. If I'm ok=
ay
> to wait in a queue, I should have the option for same affordability for
> minimum fees in the future as it is today. (Like we still have posts today
> while email still exists).
If we're expecting fee revenue to be significant in the future - with const=
ant
backlogs of low-fee txs - lowering the dust limit now is a good way to ensu=
re
the entire ecosystem is ready to deal with those conditions. We're fairly c=
lose
to blocks being full, so you can't argue that the dust limit provides value=
by
reducing block usage. All it achieves is artificially lowering mempool usag=
e,
putting the Bitcoin system in a no-backlog state that's quite unlike how we=
're
expecting Bitcoin to operate in the future. And indeed, the state Bitcoin c=
an
operate in at any moment if there is a demand spike.
So I'd suggest removing the fixed dust limit entirely and relying purely on=
the
mempool size limit to determine what is or is not dust.
-- =
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
