summaryrefslogtreecommitdiff
path: root/5d/23e998363893f08bdfbf5cdc17ad2326870f98
blob: 79471e8b05b8a2dfdf8909b5648dbf32fb7e76e1 (plain)
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
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 09E5CC000E;
 Tue, 10 Aug 2021 00:30:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id D916C40304;
 Tue, 10 Aug 2021 00:30:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id iQdYnewWwyXL; Tue, 10 Aug 2021 00:30:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [IPv6:2a00:1450:4864:20::530])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 48076402CA;
 Tue, 10 Aug 2021 00:30:20 +0000 (UTC)
Received: by mail-ed1-x530.google.com with SMTP id b7so27482212edu.3;
 Mon, 09 Aug 2021 17:30:20 -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=Z5kJdIDROV3tvBBV8MFjVQKc42wnGuIoZ8MVntq6zkw=;
 b=rmRhz8MLcLhivKEuqDQYlgvqH/zjLJYe2ZPKelBayhJ38qC5fGiOsLZjIlvqKP8XCj
 2L5xpuPYaxnnlNXCBPxJU2gpCRq/LdzWLLnSho3/5cSwoUIGJm1jUxbCn/j4asrwgEM9
 yQSbu4QnMOjGp3zwFEVish7d1ZNT4zSD9I5Iw+OCXJmA0f/goMnD4BkvkdVJ6phbAf+R
 DkR5KWmWkrxhZ7MXG1c4/B+FiySXgicBUma0agFr8Uh0w1sBoqfS2X2+6+YO0Kpomc7d
 Y+osLUTZSN5gD8lWhdAS5eteS5+Gj71rky2yF9KRxAmHJvpwbt14hM4QsfhlytKJT/q3
 eeeg==
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=Z5kJdIDROV3tvBBV8MFjVQKc42wnGuIoZ8MVntq6zkw=;
 b=TEz+R3mtBGAASBJDpvhhDE3x7iAN6KHxhvRLMr7mObsfwbMF7aWedVNcEknTEBcKo9
 Zt/gBxxxoAIjbADvpiztTGN0AvPtnZy3+l/GPFZhNflIacOpEyyBquMbO4dM9KwHUhbI
 HclnXQu1DZpnBjJi9vORvBLQZ+ql3i7JW4KOZBRLTVoifIPMPogDGbUowAmwnc2L6yv4
 aSpVIKvO2q5ogR9Bjzmv8tLsVP3sxfCPEzg2uA4G+x4FzdCTH8MiyF5iCi23wElmI6CS
 TwWGJu561RKbcKuefU8g/T28RYaJbZeltBnmDp/+mJUc5cfxeVs3jwUR6wCtk9pBBpLl
 S4/Q==
X-Gm-Message-State: AOAM531WiluHg575fEZVrc9xlnYjGdEHb/nm5VpjuIOzxlY7cFgNyuKq
 R1A96/OwF5r3P3K6Sa3ICy9sc0NmjflS69gDC+4=
X-Google-Smtp-Source: ABdhPJyQ2vxkOePtY0LT5rmch2PXYxWMkFM0BEIsCLS+BjV6ecf6Wx/dK5+mWp2l8t8hl9a0/Tt0CL5ic33DWkheYLY=
X-Received: by 2002:a50:cc06:: with SMTP id m6mr1315021edi.97.1628555418183;
 Mon, 09 Aug 2021 17:30:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
In-Reply-To: <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 9 Aug 2021 17:30:02 -0700
Message-ID: <CAGpPWDZn6dcuEJXRjUP4VYvJbL9u4mmVoS9xTVzBrGWOM5CeZw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000032aba005c9299b3d"
X-Mailman-Approved-At: Tue, 10 Aug 2021 10:13:00 +0000
Cc: 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 00:30:25 -0000

--00000000000032aba005c9299b3d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 5) should we ever do confidential transactions we can't prevent it withou=
t compromising
privacy / allowed transfers

I wanted to mention the dubiousness of adding confidential transactions to
bitcoin. Because adding CT would eliminate the ability for users to audit
the supply of Bitcoin, I think its incredibly unlikely to ever happen. I'm
in the camp that we shouldn't do anything that prevents people from
auditing the supply. I think that camp is probably pretty large. Regardless
of what I think should happen there, and even if CT were to eventually
happen in bitcoin, I don't think that future possibility is a good reason
to change the dust limit today.

It seems like dust is a scalability problem regardless of whether we use
Utreexo eventually or not, tho an accumulator would help a ton. One idea
would be to destroy/delete dust at some point in the future. However, even
if we were to plan to do this, I still don't think the dust limit should be
removed. But the dust limit should probably be lowered a bit, given that
the 546 sats limit is about 7 cents and its very doable to send 1 sat/vbyte
transactions, so lowering it to 200 sats seems reasonable.


On Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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]. Of course, we
> can adjust the LN security model around dust handling to mitigate the
> safety risk in case of adversarial settings, but ultimately the standard
> dust limit creates a  "hard" bound, and as such it introduces a trust
> vector in the reliability of your peer to not goes
> onchain with a commitment heavily-loaded with dust-HTLC you own.
>
> LN node operators might be willingly to compensate this "dust" trust
> vector by relying on side-trust model, such as PKI to authenticate their
> peers or API tokens (LSATs, PoW tokens), probably not free from
> consequences for the "openness" of the LN topology...
>
> Further, I think any authoritative setting of the dust limit presents the
> risk of becoming ill-adjusted  w.r.t to market realities after a few mont=
hs
> or years, and would need periodic reevaluations. Those reevaluations, if
> not automated, would become a vector of endless dramas and bikeshedding a=
s
> the L2s ecosystems grow bigger...
>
> Note, this would also constrain the design space of newer fee schemes.
> Such as negotiated-with-mining-pool and discounted consolidation during l=
ow
> feerate periods deployed by such producers of low-value outputs.
> `
> Moreover as an operational point, if we proceed to such an increase on th=
e
> base-layer, e.g to 20 sat/vb, we're going to severely damage the
> propagation of any LN transaction, where a commitment transaction is buil=
t
> with less than 20 sat/vb outputs. Of course, core's policy deployment on
> the base layer is gradual, but we should first give a time window for the
> LN ecosystem to upgrade and as of today we're still devoid of the mechani=
sm
> to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence
> protocol [1]).
>
> That said, as raised by other commentators, I don't deny we have a
> long-term tension between L2 nodes and full-nodes operators about the UTX=
O
> set growth, but for now I would rather solve this with smarter engineerin=
g
> such as utreexo on the base-layer side or multi-party shared-utxo or
> compressed colored coins/authentication smart contracts (e.g
> opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than
> altering the current equilibrium.
>
> I think the status quo is good enough for now, and I believe we would be
> better off to learn from another development cycle before tweaking the du=
st
> limit in any sense.
>
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714=
.html
> [1] https://github.com/lightningnetwork/lightning-rfc/pull/869
>
> Le dim. 8 ao=C3=BBt 2021 =C3=A0 14:53, Jeremy <jlrubin@mit.edu> a =C3=A9c=
rit :
>
>> We should remove the dust limit from Bitcoin. Five reasons:
>>
>> 1) it's not our business what outputs people want to create
>> 2) dust outputs can be used in various authentication/delegation smart
>> contracts
>> 3) dust sized htlcs in lightning (
>> https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-t=
hat-would-typically-be-considered-dust-through-the-light)
>> force channels to operate in a semi-trusted mode which has implications
>> (AFAIU) for the regulatory classification of channels in various
>> jurisdictions; agnostic treatment of fund transfers would simplify this
>> (like getting a 0.01 cent dividend check in the mail)
>> 4) thinly divisible colored coin protocols might make use of sats as
>> value markers for transactions.
>> 5) should we ever do confidential transactions we can't prevent it
>> without compromising privacy / allowed transfers
>>
>> The main reasons I'm aware of not allow dust creation is that:
>>
>> 1) dust is spam
>> 2) dust fingerprinting attacks
>>
>> 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by
>> well behaved wallets to not redeem outputs that cost more in fees than t=
hey
>> are worth.
>>
>> cheers,
>>
>> jeremy
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>> <https://twitter.com/JeremyRubin>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000032aba005c9299b3d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"color:rgb(80,0,80)">&gt; 5) should we ever =
do confidential transactions we can&#39;t prevent it without</span><span st=
yle=3D"color:rgb(80,0,80)">=C2=A0compromising privacy / allowed transfers</=
span><br><div><span style=3D"color:rgb(80,0,80)"><br></span></div>I wanted =
to mention the dubiousness of adding confidential transactions to bitcoin. =
Because=C2=A0adding CT would eliminate the ability=C2=A0for users to audit =
the supply of Bitcoin, I think its=C2=A0incredibly unlikely to ever happen.=
 I&#39;m in the camp that we shouldn&#39;t do anything that prevents people=
 from auditing the supply. I think that camp is probably pretty=C2=A0large.=
 Regardless of what I think should=C2=A0happen there, and even if CT were t=
o eventually happen in bitcoin, I don&#39;t think that future=C2=A0possibil=
ity is a good reason to change the dust limit today.<div><br><div>It seems =
like dust is a scalability problem regardless of whether we use Utreexo eve=
ntually or not, tho an accumulator would help a ton. One idea would be to d=
estroy/delete dust at some point in the future. However, even if we were to=
 plan to do this, I still don&#39;t think the dust limit should be removed.=
 But the dust limit should probably be lowered a bit, given that the 546 sa=
ts limit is about 7 cents and its very doable to send 1 sat/vbyte transacti=
ons, so lowering it to 200 sats seems reasonable.=C2=A0=C2=A0</div><div><br=
></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>I&#39;m pretty conservative abo=
ut increasing the standard dust limit in any way. This would convert a high=
er percentage of LN channels capacity into dust, which is coming with a low=
ering of funds safety [0]. Of course, we can adjust the LN security model a=
round dust handling to mitigate the safety risk in case of adversarial sett=
ings, but ultimately the standard dust limit creates a=C2=A0 &quot;hard&quo=
t; bound, and as such it introduces a trust vector in the reliability of yo=
ur peer to not goes<br>onchain with a commitment heavily-loaded with dust-H=
TLC you own.<br><br>LN node operators might be willingly to compensate this=
 &quot;dust&quot; trust vector by relying on side-trust model, such as PKI =
to authenticate their peers or API tokens (LSATs, PoW tokens), probably not=
 free from consequences for the &quot;openness&quot; of the LN topology...<=
br><br>Further, I think any authoritative setting of the dust limit present=
s the risk of becoming ill-adjusted=C2=A0 w.r.t to market realities after a=
 few months or years, and would need periodic reevaluations. Those reevalua=
tions, if not automated, would become a vector of endless dramas and bikesh=
edding as the L2s ecosystems grow bigger...<br><br>Note, this would also co=
nstrain the design space of newer fee schemes. Such as negotiated-with-mini=
ng-pool and discounted consolidation during low feerate periods deployed by=
 such producers of low-value outputs.<br>`<br>Moreover as an operational po=
int, if we proceed to such an increase on the base-layer, e.g to 20 sat/vb,=
 we&#39;re going to severely damage the propagation of any LN transaction, =
where a commitment transaction is built with less than 20 sat/vb outputs. O=
f course, core&#39;s policy deployment on the base layer is gradual, but we=
 should first give a time window for the LN ecosystem to upgrade and as of =
today we&#39;re still devoid of the mechanism to do it cleanly and asynchro=
nously (e.g dynamic upgrade or quiescence protocol [1]).<br><br>That said, =
as raised by other commentators, I don&#39;t deny we have a long-term tensi=
on between L2 nodes and full-nodes operators about the UTXO set growth, but=
 for now I would rather solve this with smarter engineering such as utreexo=
 on the base-layer side or multi-party shared-utxo or compressed colored co=
ins/authentication smart contracts (e.g opentimestamp&#39;s merkle tree in =
OP_RETURN) on the upper layers rather than altering the current equilibrium=
.<br><br>I think the status quo is good enough for now, and I believe we wo=
uld be better off to learn from another development cycle before tweaking t=
he dust limit in any sense.<br><br></div>Antoine<br><div><br>[0] <a href=3D=
"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.=
html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightni=
ng-dev/2020-May/002714.html</a><br>[1] <a href=3D"https://github.com/lightn=
ingnetwork/lightning-rfc/pull/869" target=3D"_blank">https://github.com/lig=
htningnetwork/lightning-rfc/pull/869</a><br></div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0dim. 8 ao=C3=BBt =
2021 =C3=A0=C2=A014:53, Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu" targe=
t=3D"_blank">jlrubin@mit.edu</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">We should remove the dust limit from Bitcoin. Five reaso=
ns:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)">1) it&#39;s not our business what outputs people want to cr=
eate</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)">2) dust outputs can be used i=
n various authentication/delegation smart contracts</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">3) dust sized htlcs in lightning (<a href=3D"https://bitc=
oin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typic=
ally-be-considered-dust-through-the-light" target=3D"_blank">https://bitcoi=
n.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typical=
ly-be-considered-dust-through-the-light</a>) force channels to operate in a=
 semi-trusted mode which has implications (AFAIU) for the regulatory classi=
fication of channels in various jurisdictions; agnostic treatment of fund t=
ransfers=C2=A0would simplify this (like getting a 0.01 cent dividend check =
in the mail)</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">4) thinly divisible c=
olored coin protocols might make use of sats as value markers for transacti=
ons.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)">5) should we ever do confiden=
tial transactions we can&#39;t prevent it without compromising=C2=A0privacy=
 / allowed transfers</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">The main reasons I&#39;m aware of not allo=
w dust creation is that:</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">1) dust is spam</div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">2) dust fingerprinting attacks</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1 is (IMO) no=
t valid given the 5 reasons above, and 2 is preventable by well behaved wal=
lets to not redeem outputs that cost more in fees than they are worth.</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)">cheers,</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">jeremy</div><br clear=3D"all"><div><div dir=3D"=
ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" tar=
get=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" =
target=3D"_blank"></a></div></div></div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000032aba005c9299b3d--