From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 15CCAC000E; Sun, 8 Aug 2021 18:53:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0373C606C4; Sun, 8 Aug 2021 18:53:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hB6wpmLmNMc; Sun, 8 Aug 2021 18:53:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp3.osuosl.org (Postfix) with ESMTPS id BB3E7605C5; Sun, 8 Aug 2021 18:53:09 +0000 (UTC) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 178Ir7PC021132 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 8 Aug 2021 14:53:08 -0400 Received: by mail-io1-f52.google.com with SMTP id l20so22014804iom.4; Sun, 08 Aug 2021 11:53:08 -0700 (PDT) X-Gm-Message-State: AOAM532S/SIl0xCRLLdesnz0jZj6+FBmY4cndZR7JLSEWznxaemK2GQZ 1bCePkdWJVeY2P8PnUW2bzCU+8t0p+u83iyGXHo= X-Google-Smtp-Source: ABdhPJymhuDIxJBIMVtpIsaIyTsHfz2U75c4Sww549OVISAa4Zh1lokwaGjqkiM6t/ltmfH8ZyozBpHrjj1IPDQHk5Y= X-Received: by 2002:a6b:780c:: with SMTP id j12mr203417iom.97.1628448787334; Sun, 08 Aug 2021 11:53:07 -0700 (PDT) MIME-Version: 1.0 From: Jeremy Date: Sun, 8 Aug 2021 11:52:55 -0700 X-Gmail-Original-Message-ID: Message-ID: To: lightning-dev , Bitcoin development mailing list Content-Type: multipart/alternative; boundary="00000000000081146805c910c735" Subject: [bitcoin-dev] Removing the Dust Limit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 18:53:11 -0000 --00000000000081146805c910c735 Content-Type: text/plain; charset="UTF-8" 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 -- @JeremyRubin --00000000000081146805c910c735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We should remove the dust= limit from Bitcoin. Five reasons:
<= br>
1) it's not our business what= outputs people want to create
2) dus= t outputs can be used in various authentication/delegation smart contracts<= /div>
3) dust sized htlcs in lightning (https://bitc= oin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typic= ally-be-considered-dust-through-the-light) force channels to operate in= a semi-trusted mode which has implications (AFAIU) for the regulatory clas= sification of channels in various jurisdictions; agnostic treatment of fund= transfers=C2=A0would simplify this (like getting a 0.01 cent dividend chec= k in the mail)
4) thinly divisible co= lored coin protocols might make use of sats as value markers for transactio= ns.
5) should we ever do confidential= transactions we can't prevent it without compromising=C2=A0privacy / a= llowed transfers

The main reasons I'm aware of not allow dust cre= ation is that:

1) dust is spam
2) dust fingerprinting attacks

=
1 is (IMO) not valid given the 5 rea= sons above, and 2 is preventable by well behaved wallets to not redeem outp= uts that cost more in fees than they are worth.

cheers,

jeremy<= /div>
--00000000000081146805c910c735--