1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
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--
|
