diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2021-08-10 18:37:48 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-08-10 22:38:05 +0000 |
| commit | 81307a9ff41748e1bbabb481fdd8bcde6c1e6c4a (patch) | |
| tree | 3df9b693a0166aba6bbf9c9e33310d832f513795 /27 | |
| parent | 68d0a5c7688db8a8924627c6498a0171abd8680c (diff) | |
| download | pi-bitcoindev-81307a9ff41748e1bbabb481fdd8bcde6c1e6c4a.tar.gz pi-bitcoindev-81307a9ff41748e1bbabb481fdd8bcde6c1e6c4a.zip | |
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Diffstat (limited to '27')
| -rw-r--r-- | 27/466b9ffca4cfdc1b0fea831459981b4e9e21e6 | 314 |
1 files changed, 314 insertions, 0 deletions
diff --git a/27/466b9ffca4cfdc1b0fea831459981b4e9e21e6 b/27/466b9ffca4cfdc1b0fea831459981b4e9e21e6 new file mode 100644 index 000000000..a5cb6240b --- /dev/null +++ b/27/466b9ffca4cfdc1b0fea831459981b4e9e21e6 @@ -0,0 +1,314 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 28FCBC000E; + Tue, 10 Aug 2021 22:38:05 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 1E7FB82FAE; + Tue, 10 Aug 2021 22:38:05 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id SIIsZn6eBUlO; Tue, 10 Aug 2021 22:38:03 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com + [IPv6:2a00:1450:4864:20::32c]) + by smtp1.osuosl.org (Postfix) with ESMTPS id A557482EFC; + Tue, 10 Aug 2021 22:38:03 +0000 (UTC) +Received: by mail-wm1-x32c.google.com with SMTP id + m36-20020a05600c3b24b02902e67543e17aso2653580wms.0; + Tue, 10 Aug 2021 15:38:03 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=IM35/Fh95zFsGC/Mq/dq2Dmn+uUUTsjVYDgGq76ytRg=; + b=kG9OUeE2YUV+eJ43uBeikigDaosOImb0M2Tv0d1u9FZ5ML6gOb3sAtSbHWNpNi9LiN + 8NX8uqBGymQTpv/UVfJnsCEoSsMbT+puPXGtXH3OHr/d6kTgVDz07aXeH1uyCjWsmpdj + wLwpda3QWIiSJ0ksAo9IXIZUEIIzpmRITPysw4X+i6zdnQko2Z9pu69kANcRWv+D/Go2 + TQn2ZCv70uRI02Zd/3g2SSbCE1Ka5Tj37BPGH+WLukEWWv1leLaS0BAaFLN11akieVnM + OB5jKrRgS7Y8NnTfghXx+PSH2NQk3epN7CoggAJxzFWJ1GSXN9u2wiMEi+0RNM9r9aWL + HjoA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=IM35/Fh95zFsGC/Mq/dq2Dmn+uUUTsjVYDgGq76ytRg=; + b=Ae44iO4ift1M/wVMQkr9MuTmPMO9k2NmMEXAhOGJ6N4izrZugIoY3GqDMgneoqMiKP + 17XMwlUoRVw+E208hj42k893KcfEFnS45DbAb9aqw9uLfSqsOW1nq/M2DYMXzQl/zgcy + ZggdbY2DWpQ5Bx06LXRAESp473RyeyCJkujktgcQ9SS0V5ZsQ2FEDtst6hQuF8MI3Vj7 + 0MNEkX+Dee1c0vUOn42DM5aNYI1U5Oj+9Xegzbpxnb5F2qrv180rBRNNO20Rv0Tm462I + JjVmvBFRTZPc1Zh/K3LcIeTn0FC9NDjm2OvBQLAS8lKcBAlnNc/jvp09IN0VS/zqhw5X + rGmQ== +X-Gm-Message-State: AOAM533G3fhoo8QT2UMvby9J91hdIr6QndcRTYOzmpb+YRcFohRASxpH + 7igfV69gCQ/Vi/f1iuPredKQt9xn+c2bFp3kifs= +X-Google-Smtp-Source: ABdhPJzONRRNCl1j6NUlYGUsMSFigUVKZUDNMq/hUCmu/oON1VtTwRdWRakhk0mJfuwPnlmROxVq+LbqTKC4PT730mU= +X-Received: by 2002:a05:600c:3581:: with SMTP id + p1mr24662111wmq.1.1628635081802; + Tue, 10 Aug 2021 15:38:01 -0700 (PDT) +MIME-Version: 1.0 +References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com> + <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com> + <20210810061441.6rg3quotiycomcp6@ganymede> +In-Reply-To: <20210810061441.6rg3quotiycomcp6@ganymede> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Tue, 10 Aug 2021 18:37:48 -0400 +Message-ID: <CALZpt+G0CRitWLwUTA+7NnnZWNNrsEmFTMW3VmFSQ=vzXZOQGA@mail.gmail.com> +To: "David A. Harding" <dave@dtrt.org> +Content-Type: multipart/alternative; boundary="00000000000085086205c93c2716" +X-Mailman-Approved-At: Tue, 10 Aug 2021 22:42:39 +0000 +Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>, + lightning-dev <lightning-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 10 Aug 2021 22:38:05 -0000 + +--00000000000085086205c93c2716 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +> As developers, we have no +control over prevailing feerates, so this is a problem LN needs to deal +with regardless of Bitcoin Core's dust limit. + +Right, as of today, we're going to trim-to-dust any commitment output of +which the value is inferior to the transaction owner's +`dust_limit_satoshis` plus the HTLC-claim (either success/timeout) fee at +the agreed on feerate. So the feerate is the most significant variable in +defining what's a LN *uneconomical output*. + +IMO this approach presents annoying limitations. First, you still need to +come with an agreement among channel operators on the mempools feerate. +Such agreement might be problematic to find, as on one side you would like +to let your counterparty free to pick up a feerate gauged as efficient for +the confirmation of their transactions but at the same time not too high to +burn to fees your low-values HTLCs that *your* fee-estimator judged as sane +to claim. + +Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime +of the HTLC. A HTLC might be considered as dust at block 100, at which +mempools are full. Though its expiration only occurs at block 200, at which +mempools are empty and this HTLC is fine to claim again. I think this +inaccuracy will even become worse with a wider deployment of long-lived +routed packets over LN, such as DLCs or hodl invoices. + +All this to say, if for those reasons LN devs remove feerate negotiation +from the trim-to-dust definition to a static feerate, it would likely put a +higher pressure on the full-nodes operators, as the number of uneconomical +outputs might increase. + +(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) + +> They could also use trustless probabalistic payments, which have been +discussed in the context of LN for handling the problem of payments too +small to be represented onchain since early 2016: +https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCa= +ZXgvDN0U/edit?pref=3D2&pli=3D1#slide=3Did.g85f425098 + +Thanks to bringing to the surface probabilistic payments, yes that's a +worthy alternative approach for low-value payments to keep in mind. + +Le mar. 10 ao=C3=BBt 2021 =C3=A0 02:15, David A. Harding <dave@dtrt.org> a = +=C3=A9crit : + +> On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote: +> > I'm pretty conservative about increasing the standard dust limit in any +> > way. This would convert a higher percentage of LN channels capacity int= +o +> > dust, which is coming with a lowering of funds safety [0]. +> +> I think that reasoning is incomplete. There are two related things here: +> +> - **Uneconomical outputs:** outputs that would cost more to spend than +> the value they contain. +> +> - **Dust limit:** an output amount below which Bitcoin Core (and other +> nodes) will not relay the transaction containing that output. +> +> Although raising the dust limit can have the effect you describe, +> increases in the minimum necessary feerate to get a transaction +> confirmed in an appropriate amount of time also "converts a higher +> percentage of LN channel capacity into dust". As developers, we have no +> control over prevailing feerates, so this is a problem LN needs to deal +> with regardless of Bitcoin Core's dust limit. +> +> (Related to your linked thread, that seems to be about the risk of +> "burning funds" by paying them to a miner who may be a party to the +> attack. There's plenty of other alternative ways to burn funds that can +> change the risk profile.) +> +> > the standard dust limit [...] introduces a trust vector +> +> My point above is that any trust vector is introduced not by the dust +> limit but by the economics of outputs being worth less than they cost to +> spend. +> +> > LN node operators might be willingly to compensate this "dust" trust +> vector +> > by relying on side-trust model +> +> They could also use trustless probabalistic payments, which have been +> discussed in the context of LN for handling the problem of payments too +> small to be represented onchain since early 2016: +> +> https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLr= +CaZXgvDN0U/edit?pref=3D2&pli=3D1#slide=3Did.g85f425098_0_178 +> +> (Probabalistic payments were discussed in the general context of Bitcoin +> well before LN was proposed, and Elements even includes an opcode for +> creating them.) +> +> > smarter engineering such as utreexo on the base-layer side +> +> Utreexo doesn't solve this problem. Many nodes (such as miners) will +> still want to store the full UTXO set and access it quickly, Utreexo +> proofs will grow in size with UTXO set size (though, at best, only +> log(n)), so full node operators will still not want their bandwidth +> wasted by people who create UTXOs they have no reason to spend. +> +> > I think the status quo is good enough for now +> +> I agree. +> +> -Dave +> + +--00000000000085086205c93c2716 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">> =C2=A0As developers, we have no<br>control over preva= +iling feerates, so this is a problem LN needs to deal<br>with regardless of= + Bitcoin Core's dust limit.<br><br>Right, as of today, we're going = +to trim-to-dust any commitment output of which the value is inferior to the= + transaction owner's `dust_limit_satoshis` plus the HTLC-claim (either = +success/timeout) fee at the agreed on feerate. So the feerate is the most s= +ignificant variable in defining what's a LN *uneconomical output*.<br><= +br>IMO this approach presents annoying limitations. First, you still need t= +o come with an agreement among channel operators on the mempools feerate. S= +uch agreement might be problematic to find, as on one side you would like t= +o let your counterparty free to pick up a feerate gauged as efficient for t= +he confirmation of their transactions but at the same time not too high to = +burn to fees your low-values HTLCs that *your* fee-estimator judged as sane= + to claim.<br><br>Secondly, the trim-to-dust evaluation doesn't correct= +ly match the lifetime of the HTLC. A HTLC might be considered as dust at bl= +ock 100, at which mempools are full. Though its expiration only occurs at b= +lock 200, at which mempools are empty and this HTLC is fine to claim again.= + I think this inaccuracy will even become worse with a wider deployment of = +long-lived routed packets over LN, such as DLCs or hodl invoices.<br><br>Al= +l this to say, if for those reasons LN devs remove feerate negotiation from= + the trim-to-dust definition to a static feerate, it would likely put a hig= +her pressure on the full-nodes operators, as the number of uneconomical out= +puts might increase.<br><br>(From a LN viewpoint, I would say we're try= +ing 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&quo= +t; price means you trust more your LN counterparty)<br><br>> They could = +also use trustless probabalistic payments, which have been<br>discussed in = +the context of LN for handling the problem of payments too<br>small to be r= +epresented onchain since early 2016:<br><a href=3D"https://docs.google.com/= +presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=3D2&a= +mp;pli=3D1#slide=3Did.g85f425098">https://docs.google.com/presentation/d/1G= +4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=3D2&pli=3D1#slide= +=3Did.g85f425098</a><br><br>Thanks to bringing to the surface probabilistic= + payments, yes that's a worthy alternative approach for low-value payme= +nts to keep in mind.<br></div><br><div class=3D"gmail_quote"><div dir=3D"lt= +r" class=3D"gmail_attr">Le=C2=A0mar. 10 ao=C3=BBt 2021 =C3=A0=C2=A002:15, D= +avid A. Harding <<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>> = +a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= +gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= +ex">On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote:<br> +> I'm pretty conservative about increasing the standard dust limit i= +n any<br> +> way. This would convert a higher percentage of LN channels capacity in= +to<br> +> dust, which is coming with a lowering of funds safety [0]. <br> +<br> +I think that reasoning is incomplete.=C2=A0 There are two related things he= +re:<br> +<br> +- **Uneconomical outputs:** outputs that would cost more to spend than<br> +=C2=A0 the value they contain.<br> +<br> +- **Dust limit:** an output amount below which Bitcoin Core (and other<br> +=C2=A0 nodes) will not relay the transaction containing that output.<br> +<br> +Although raising the dust limit can have the effect you describe, <br> +increases in the minimum necessary feerate to get a transaction<br> +confirmed in an appropriate amount of time also "converts a higher<br> +percentage of LN channel capacity into dust".=C2=A0 As developers, we = +have no<br> +control over prevailing feerates, so this is a problem LN needs to deal<br> +with regardless of Bitcoin Core's dust limit.<br> +<br> +(Related to your linked thread, that seems to be about the risk of<br> +"burning funds" by paying them to a miner who may be a party to t= +he<br> +attack.=C2=A0 There's plenty of other alternative ways to burn funds th= +at can<br> +change the risk profile.)<br> +<br> +> the standard dust limit [...] introduces a trust vector <br> +<br> +My point above is that any trust vector is introduced not by the dust<br> +limit but by the economics of outputs being worth less than they cost to<br= +> +spend.<br> +<br> +> LN node operators might be willingly to compensate this "dust&quo= +t; trust vector<br> +> by relying on side-trust model<br> +<br> +They could also use trustless probabalistic payments, which have been<br> +discussed in the context of LN for handling the problem of payments too<br> +small to be represented onchain since early 2016:<br> +<a href=3D"https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIU= +kJc2khnLrCaZXgvDN0U/edit?pref=3D2&pli=3D1#slide=3Did.g85f425098_0_178" = +rel=3D"noreferrer" target=3D"_blank">https://docs.google.com/presentation/d= +/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=3D2&pli=3D1#sli= +de=3Did.g85f425098_0_178</a><br> +<br> +(Probabalistic payments were discussed in the general context of Bitcoin<br= +> +well before LN was proposed, and Elements even includes an opcode for<br> +creating them.)<br> +<br> +> smarter engineering such as utreexo on the base-layer side <br> +<br> +Utreexo doesn't solve this problem.=C2=A0 Many nodes (such as miners) w= +ill<br> +still want to store the full UTXO set and access it quickly,=C2=A0 Utreexo<= +br> +proofs will grow in size with UTXO set size (though, at best, only<br> +log(n)), so full node operators will still not want their bandwidth<br> +wasted by people who create UTXOs they have no reason to spend.<br> +<br> +> I think the status quo is good enough for now<br> +<br> +I agree.<br> +<br> +-Dave<br> +</blockquote></div> + +--00000000000085086205c93c2716-- + |