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>
Subject: Re: [bitcoin-dev] Removing the Dust Limit
Date: Sat, 12 Mar 2022 14:02:24 +0100 [thread overview]
Message-ID: <158448037-69ce54a3e9d127c104583392edfcbf55@pmq5v.m5r2.onet> (raw)
> We should remove the dust limit from Bitcoin.
Any node operator can do that. Just put "dustrelayfee=0.00000000" in your bitcoin.conf.
And there is more: you can also conditionally allow free transactions:
mintxfee=0.00000001
minrelaytxfee=0.00000000
blockmintxfee=0.00000000
Then, when using getblocktemplate you will get transactions with the highest 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 need 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•linuxfoundation.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 contracts
3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light) force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (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 privacy / 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 well behaved wallets to not redeem outputs that cost more in fees than they are worth.
cheers,
jeremy
next reply other threads:[~2022-03-12 13:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-12 13:02 vjudeu [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-08-09 10:25 Prayank
2021-08-09 11:58 ` Karl
2021-08-08 18:52 Jeremy
2021-08-08 21:14 ` Matt Corallo
2021-08-08 21:41 ` Oleg Andreev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=158448037-69ce54a3e9d127c104583392edfcbf55@pmq5v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox