summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid A. Harding <dave@dtrt.org>2021-08-09 20:14:41 -1000
committerbitcoindev <bitcoindev@gnusha.org>2021-08-10 06:15:38 +0000
commit1d22ecf2eaf1e99d4ad275553fa092ff7d6c4ef8 (patch)
treefec6ecaa84a0cd9361e8bbe986ceeae5d042a4c4
parent0c2adf6b11a8f508a53601df29b23047ddc9ec35 (diff)
downloadpi-bitcoindev-1d22ecf2eaf1e99d4ad275553fa092ff7d6c4ef8.tar.gz
pi-bitcoindev-1d22ecf2eaf1e99d4ad275553fa092ff7d6c4ef8.zip
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
-rw-r--r--57/19c5e25d31ee913592696eced005ad955d056f153
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--
+