public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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




             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 [bitcoin-dev] Removing the Dust Limit 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.pl \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jlrubin@mit.edu \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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