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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
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--
|