Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: Jeremy <jlrubin@mit.edu>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Date: Sat, 12 Mar 2022 14:02:24 +0100
Message-Id: <158448037-69ce54a3e9d127c104583392edfcbf55@pmq5v.m5r2.onet>
Subject: Re: [bitcoin-dev] Removing the Dust Limit
Precedence: list

> We should remove the dust limit from Bitcoin.

Any node operator can do that. Just put "dustrelayfee=3D0.00000000" in your=
 bitcoin.conf.

And there is more: you can also conditionally allow free transactions:

mintxfee=3D0.00000001
minrelaytxfee=3D0.00000000
blockmintxfee=3D0.00000000

Then, when using getblocktemplate you will get transactions with the highes=
t fees first anyway, and you include cheap or free transactions in the end,=
 if there will be enough room for them.

So, all of those settings are in the hands of node operators, there is no n=
eed to change the source code, all you need is to convince nodes to change =
their settings.


On 2021-08-08 20:53:28 user Jeremy via bitcoin-dev <bitcoin-dev@lists.linux=
foundation.org> wrote:
We should remove the dust limit from Bitcoin. Five reasons:


1) it's not our business what outputs people want to create
2) dust outputs can be used in various authentication/delegation smart cont=
racts
3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/questio=
ns/46730/can-you-send-amounts-that-would-typically-be-considered-dust-throu=
gh-the-light) force channels to operate in a semi-trusted mode which has im=
plications (AFAIU) for the regulatory classification of channels in various=
 jurisdictions; agnostic treatment of fund transfers=C2=A0would simplify th=
is (like getting a 0.01 cent dividend check in the mail)
4) thinly divisible colored coin protocols might make use of sats as value =
markers for transactions.
5) should we ever do confidential transactions we can't prevent it without =
compromising=C2=A0privacy / allowed transfers


The main reasons I'm aware of not allow dust creation is that:


1) dust is spam
2) dust fingerprinting attacks


1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by wel=
l behaved wallets to not redeem outputs that cost more in fees than they ar=
e worth.


cheers,


jeremy