Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
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>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Precedence: list

> 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