From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 09EE9C000E; Thu, 12 Aug 2021 22:03:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id EA043402C1; Thu, 12 Aug 2021 22:03:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.079 X-Spam-Level: * X-Spam-Status: No, score=1.079 tagged_above=-999 required=5 tests=[BAYES_50=0.8, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 gE4fjTlp-dRp; Thu, 12 Aug 2021 22:03:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp2.osuosl.org (Postfix) with ESMTPS id 0ABAC4027C; Thu, 12 Aug 2021 22:03:48 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1mEIng-0004kt-1F; Fri, 13 Aug 2021 08:03:45 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 13 Aug 2021 08:03:39 +1000 Date: Fri, 13 Aug 2021 08:03:39 +1000 From: Anthony Towns To: Antoine Riard , Bitcoin Protocol Discussion Message-ID: <20210812220339.GA3416@erisian.com.au> References: <20210810061441.6rg3quotiycomcp6@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - Cc: 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: Thu, 12 Aug 2021 22:03:50 -0000 On Tue, Aug 10, 2021 at 06:37:48PM -0400, Antoine Riard via bitcoin-dev wrote: > Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime of > the HTLC. Right: but that just means it's not something you should determine once for the HTLC, but something you should determine each time you update the channel commitment -- if fee rates are at 1sat/vb, then a 10,000 sat HTLC that's going to cost 100 sats to create the utxo and eventually claim it might be worth committing to, but if fee rates suddenly rise to 75sat/vb, then the combined cost of 7500 sat probably isn't worthwhile (and it certainly isn't worthwhile if fees rise to above 100sat/vb). That's independent of dust limits -- those only give you a fixed size lower limit or about 305sats for p2wsh outputs. Things become irrational before they become uneconomic as well: ie the 100vb is perhaps 40vb to create then 60vb to spend, so if you create the utxo anyway then the 40vb is a sunk cost, and redeeming the 10k sats might still be marginally wortwhile up until about 167sat/vb fee rate. But note the logic there: it's an uneconomic output if fees rise above 167sat/vb, but it was already economically irrational for the two parties to create it in the first place when fees were at or above 100sat/vb. If you're trying to save every sat, dust limits aren't your problem. If you're not trying to save every sat, then just add 305 sats to your output so you avoid the dust limit. (And the dust limit is only preventing you from creating outputs that would be irrational if they only required a pubkey reveal and signature to spend -- so a HTLC that requires revealing a script, two hashes, two pubkeys, a hash preimage and two signatures with the same dust threshold value for p2wsh of ~305sats would already be irrational at about 2.1sat/vb and unconomic at 2.75 sat/vb). > (From a LN viewpoint, I would say we're trying to solve a price discovery > issue, namely the cost to write on the UTXO set, in a distributed system, where > any deviation from the "honest" price means you trust more your LN > counterparty) At these amounts you're already trusting your LN counterparty to not just close the channel unilaterally at a high fee rate time and waste your funds in fees, vs doing a much for efficient mutual/cooperative close. Cheers, aj