Feedback-ID: i525146e8:Fastmail
Date: Tue, 26 Jul 2022 08:45:12 -0400
From: Peter Todd <pete@petertodd.org>
To: aaradhya@technovanti.co.in, Aaradhya Chauhan <chauhanansh.me@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Yt/h2Jv3m8ZsfZ8v@petertodd.org>
References: <CAGHFe1BXdTkPZn4r_KTxYoz0sqcMsV830dm5JTTFURxDezBnDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="WXrc+RvQX36hNhJs"
Content-Disposition: inline
In-Reply-To: <CAGHFe1BXdTkPZn4r_KTxYoz0sqcMsV830dm5JTTFURxDezBnDQ@mail.gmail.com>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Precedence: list


--WXrc+RvQX36hNhJs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-dev =
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.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--WXrc+RvQX36hNhJs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmLf4dIACgkQLly11TVR
Lze2MRAAidy0AaYtJobnQa/ocqvw1NANJY0ktX04gOxh7ehUNxUo92CCpbcEulhq
C70ibJNTkAuwORjxxCFMb9VUaxOypxEAQjZnh564UHPT12NRFTobF7VY20qUWccb
mPknZbiNAnMhbLEctgED3XY41gw/gZUjDoZyxqbUXE+u299XxdNdIasKmpNEXpln
g9ruOHdalHmEZXSLpctAHvSjAF1zDQJ8nPM2Mi2b+GRYVQc5Qo4IqmU66AF07pq4
ZGeR5cySaYE8YjiUH77PN467B5+g2hRHVjtP641ZxTZsW9N43boKNaQobZkdH0oZ
4uNy1ULezCO9XSfHVNAwZA3SOmBNPpUk6+9l6kmk+qwnLa31XDb8RURIO+HuOQJP
cO8SMVx5xp4PgEO5RMtbvp6G//oyQvNNJEgQXOnt+Fw0IAb6XpzNMDpVIyyCsmEN
c4GY1O6UvSH6yjDoPItIKkjd9df1ek4kopjJPc8wXrQQVOZ6buvHYNQ5ivZrIuIk
xFtWPmDEbGYlR5od+7mGdNq3j42NK5tJR4RUcpczi7J1idQJi7dIm1NcKrAzDqRj
qm3OVy84jO6HXXAr0zlaCOGbOmOvL2uA6Fbtq4E6P+BIh7s3PYLlqR/OvBV1I/xe
/aP/bDbPNBVDJJbog+cGotfwc6XbZA24YkgDa1P2CVML41wg0qk=
=bpJC
-----END PGP SIGNATURE-----

--WXrc+RvQX36hNhJs--