diff options
author | David A. Harding <dave@dtrt.org> | 2021-08-09 20:14:41 -1000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-08-10 06:15:38 +0000 |
commit | 1d22ecf2eaf1e99d4ad275553fa092ff7d6c4ef8 (patch) | |
tree | fec6ecaa84a0cd9361e8bbe986ceeae5d042a4c4 | |
parent | 0c2adf6b11a8f508a53601df29b23047ddc9ec35 (diff) | |
download | pi-bitcoindev-1d22ecf2eaf1e99d4ad275553fa092ff7d6c4ef8.tar.gz pi-bitcoindev-1d22ecf2eaf1e99d4ad275553fa092ff7d6c4ef8.zip |
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
-rw-r--r-- | 57/19c5e25d31ee913592696eced005ad955d056f | 153 |
1 files changed, 153 insertions, 0 deletions
diff --git a/57/19c5e25d31ee913592696eced005ad955d056f b/57/19c5e25d31ee913592696eced005ad955d056f new file mode 100644 index 000000000..42592384c --- /dev/null +++ b/57/19c5e25d31ee913592696eced005ad955d056f @@ -0,0 +1,153 @@ +Return-Path: <dave@dtrt.org> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A3DD8C000E; + Tue, 10 Aug 2021 06:15:38 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 93F3960620; + Tue, 10 Aug 2021 06:15:38 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.725 +X-Spam-Level: +X-Spam-Status: No, score=-1.725 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, RCVD_IN_XBL=0.375, + SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no +Authentication-Results: smtp3.osuosl.org (amavisd-new); + dkim=pass (1024-bit key) header.d=dtrt.org +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 96bDs3U9SSN5; Tue, 10 Aug 2021 06:15:34 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 66E2F6063A; + Tue, 10 Aug 2021 06:15:34 +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=fjmv4GIB3MCaFuG+5qDN9hZkaJpPMAlHyZuBtFJMyyI=; b=ap6PSi55mh8CbuDnXlIRXb45pU + +qIDpagIHs/2OzjaZafC/79RHxjNdzY8HicSXh3DE2qZ9+atxdcGQAU2+rV3nyALKtEKDzd+DRCkO + A5M7cbJMvlE7u+FJaEYvofoeBKRkwn7A3uuSDkfeRh+321ImSJbpEAgw99vT50lvmJow=; +Received: from harding by newmail.dtrt.org with local (Exim 4.92) + (envelope-from <dave@dtrt.org>) + id 1mDL2x-0008Df-89; Mon, 09 Aug 2021 20:15:31 -1000 +Date: Mon, 9 Aug 2021 20:14:41 -1000 +From: "David A. Harding" <dave@dtrt.org> +To: Antoine Riard <antoine.riard@gmail.com> +Message-ID: <20210810061441.6rg3quotiycomcp6@ganymede> +References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com> + <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="jnefyx4fdpdtq5cx" +Content-Disposition: inline +In-Reply-To: <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com> +User-Agent: NeoMutt/20180716 +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 06:15:38 -0000 + + +--jnefyx4fdpdtq5cx +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +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 into +> dust, which is coming with a lowering of funds safety [0].=20 + +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,=20 +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=20 + +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 vect= +or +> 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_XYyZIUkJc2khnLrCa= +ZXgvDN0U/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=20 + +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 + +--jnefyx4fdpdtq5cx +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmESGVEACgkQ2dtBqWwi +adMaow/+LTG4J3VJ4zniZ09cQOtla728pKpELzBwSk1RCeBMVaLuWg4RmZiIKFuw +PoH/wOGBzkoxCCmxDY3BIjWbOODfB0Ah8GaxDbDsbIjhxJ6XnPJrMC388APP0TML +SSyLqleUt1RPJ6Ya4iRkVJpAs3iTk2+UgAXFNqFzi/z0fiLXo+xmeEUnmT0t+0kS +KuGRbnhK3G4zV+PsMUQzmO6qriP7tTHamRzGBYVyPC92VyfibZyUhfvlN1k+GPSl +jXwOlvUoQrQwVnnMz2fTutGmAvMIZEA3XLaWO3Y+P1dNGMObpe5x4afy8uBplerR +3hVfVvwU4JbsU+eaS+6cKzFX98e8mco7UvugABDcNbK4NXW8udiC/zD1qFZsa31Z +5tYjtc9fkWm2zT7lgCZYOzyp/8SU8NJ2rb9+VhdMslxTj4rXwkq7E4okHRWlaERQ +x850Z7AJfaD2mAdbFd6OgXo+frv+UiumwuElumK8vxRVfTIkXK+FCwt7v8DeHwVW +6nkWt67vlPzJEHsS54ng9MIKen6dUx8c+OHI8sR81SzcFdHEXS1Khx9+X8F6sCGh +2TpLFiqE8yIg72EEhBm07UygV91NEzc8IELIZgigPn7ci4/6CbwK7ZoNEnqrDVOh +UGGem7a7zSDo5bYpwrBAYZ/bzg4FU+os1IKcVrqwkR7ddqnCEJY= +=FNKU +-----END PGP SIGNATURE----- + +--jnefyx4fdpdtq5cx-- + |