From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D53A8C000E; Sun, 8 Aug 2021 21:52:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B0F0C4010F; Sun, 8 Aug 2021 21:52:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.075 X-Spam-Level: * X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dtrt.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6Su4nrJE3s5; Sun, 8 Aug 2021 21:52:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from newmail.dtrt.org (newmail.dtrt.org [IPv6:2600:3c03::f03c:91ff:fe7b:78d1]) by smtp2.osuosl.org (Postfix) with ESMTPS id 157BC400AE; Sun, 8 Aug 2021 21:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org; s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZhL0vMJhq5sic081ChPC2E+Q3OiCqHkR8PApQ5/tkt0=; b=VkC9PSyC21BRWI2QQ+BgNxJr98 cVBzNeH0Ri5nzEvNiat2JJhFfKvzARChdebUeJQthpUUxry+9TwT0ptsSqntoBhckNM5OqJVTPsfU 7fqmA1WJnkuke0FhazNjp1YWZQWd++g6wv8AWzQWZKp5NzEQOKGA7XxM9/hhZEr6EnzY=; Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1mCqid-0007yI-4k; Sun, 08 Aug 2021 11:52:31 -1000 Date: Sun, 8 Aug 2021 11:51:01 -1000 From: "David A. Harding" To: Jeremy Message-ID: <20210808215101.wuaidu5ww63ajx6h@ganymede> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="doahxmd3go2jqdi4" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Cc: Bitcoin development mailing list , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-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 21:52:34 -0000 --doahxmd3go2jqdi4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote: > We should remove the dust limit from Bitcoin. Five reasons: Jeremy knows this, but to be clear for other readers, the dust limit is a policy in Bitcoin Core (and other software) where it refuses by default to relay or mine transactions with outputs below a certain amount. If nodes or miners running with non-default policy choose to relay or mine those transactions, they are not penalized (not directly, at least; there's BIP152 to consider). Question for Jeremy: would you also allow zero-value outputs? Or would you just move the dust limit down to a fixed 1-sat? I think the dust limit is worth keeping: > 1) it's not our business what outputs people want to create Every additional output added to the UTXO set increases the amount of work full nodes need to do to validate new transactions. For miners for whom fast validation of new blocks can significantly affect their revenue, larger UTXO sets increase their costs and so contributes towards centralization of mining. Allowing 0-value or 1-sat outputs minimizes the cost for polluting the UTXO set during periods of low feerates. If your stuff is going to slow down my node and possibly reduce my censorship resistance, how is that not my business? > 2) dust outputs can be used in various authentication/delegation smart > contracts All of which can also use amounts that are economically rational to spend on their own. If you're gonna use the chain for something besides value transfer, and you're already wiling to pay X in fees per onchain use, why is it not reasonable for us to ask you to put up something on the order of X as a bond that you'll actually clean up your mess when you're no longer interested in your thing? > 3) dust sized htlcs in lightning ( > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-th= at-would-typically-be-considered-dust-through-the-light) > force channels to operate in a semi-trusted mode=20 Nope, nothing is forced. Any LN node can simply refuse to accept/route HTLCs below the dust limit. > which has implications > (AFAIU) for the regulatory classification of channels in various > jurisdictions Sucks for the people living there. They should change their laws. If they can't do that, they should change their LN node policies not to route uneconomic HTLCs. We shouldn't make Bitcoin worse to make complying with regulations easier. I also doubt your proposed solution fixes the problem. Any LN node that accepts an uneconomic HTLC cannot recover that value, so the money is lost either way. Any sane regulation would treat losing value to transaction fees the same as losing value to uneconomical conditions. Finally, if LN nodes start polluting the UTXO set with no economic way to clean up their mess, I think that's going to cause tension between full node operators and LN node operators. > agnostic treatment of fund transfers would simplify this > (like getting a 0.01 cent dividend check in the mail) I'm not sure I understand this point. It sounds to me like you're comparing receiving an uneconomic output to receiving a check that isn't worth the time to cash. But the costs of checks are borne only by the people who send, receive, and process them. The costs of uneconomic outputs polluting the UTXO set are borne by every full node forever (or for every archival full node forever if non-archival nodes end up using something like utreexo). > 4) thinly divisible colored coin protocols might make use of sats as value > markers for transactions. I'm not exactly sure what you're talking about, but if Alice wants to communicate the number n onchain, she can do: if n < dust: nSequence =3D 0x0000 + n # should probably check endianess else: nValue =3D n There's at least 15 bits of nSequence currently without consensus or policy meaning, and the dust limits are currently in the hundreds of sat, so there's plenty of space. Alice could probably also communicate the same thing by grinding her output script's hash or pubkey; again, with dust limits just being hundreds of sats, that's not too much grinding. > 5) should we ever do confidential transactions we can't prevent it without > compromising privacy / allowed transfers I'm not an expert, but it seems to me that you can do that with range proofs. The range proof for >dust doesn't need to become part of the block chain, it can be relay only. I haven't looked since they upgraded to bulletproofs, but ISTR the original CT implementation leaked the most significant digits or something (that kept down the byte size of the proofs), so maybe it was already possible to know what was certainly not dust and what might be dust. In short, it's my opinion that the dust limit is not creating any real problems, so it should be kept for its contribution to keeping full nodes faster, cheaper, and more efficient. -Dave P.S. As I prepared to send this, Matt's email arrived about "If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead." I'm in agreement with both parts of that statement. --doahxmd3go2jqdi4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmEQUcUACgkQ2dtBqWwi adOsARAAoY4ABZ2RxmcOUFKyirinPpnYxOyMYUj6RC7zhOD4fkX14bgVJzAKbmij 1bXBr8IyF8qejN9ufhP48L/EAPEZufaBY5Xw1eJ8Nct/VK+Uq+TOmjURdfg+TcDQ AWXe+Dn1YHs4DEAzsLnZCc7UVUhxRdp4haTvLM9TwenTFySF8ckQsQWr0fzLrMwb 5gamo/dROnn32ekQdsYTcLyIAJDfr/i8mO0K6yG0tO2leJbg7Z0iQkzBQPBs5AwI heMUD4DlGF1k32RJif0YN1Mfu5Q3MlOP18D9DHOpaE1cKgEOhiOU3eFdHT5iEdJa UgS/LNWru7TjErkA7jRMP37dan1WYGFxGKmboJVqUdPkTTwBCKUuOvJ1+nEFUCvh /tLX34gPToWgFPSM1w39IDTtu6MrnUcbh9kGnnJh3BxgP5Nm0AqWIbYNKNmlV3eY SWnCTwZEcDrPgNBzvTrFuOaBb+kNF8wH/ZRW0zuu6jmC7KSD98vshF+mKDcmoYyS xN9Od5TxJZfJL30w1uER3jZgiV7BjClEDFZNU7S4zxxl8aYqW9E1nuBq8c/Fbn+t LZso2HlZ4mK5MnF//FDsSTWhHnoAQ9WtZ9imUXFjOSsH+e0cwVTngTAiOowsfg8k +2Y81fDWcQDrKm2Exm8Cu4fygHgo03VsAtDKOQzSEZ0Bi8AbM4M= =hxSZ -----END PGP SIGNATURE----- --doahxmd3go2jqdi4--