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
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
|
Return-Path: <rsomsen@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 54966C0012;
Wed, 8 Dec 2021 10:46:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 35E9A41D90;
Wed, 8 Dec 2021 10:46:44 +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: 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 qE8woaRBBKYR; Wed, 8 Dec 2021 10:46:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com
[IPv6:2607:f8b0:4864:20::b34])
by smtp4.osuosl.org (Postfix) with ESMTPS id C176141D85;
Wed, 8 Dec 2021 10:46:42 +0000 (UTC)
Received: by mail-yb1-xb34.google.com with SMTP id e136so4957073ybc.4;
Wed, 08 Dec 2021 02:46:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=Hod5rOpUeVt943E7KgTPmIc3dGfYT/VglP7TuknDkh0=;
b=fQlrlCuOiu/fP+0OP5h6vbD5pyS6M7qf2Tk7hTo90XdtxdRlz10PtTlY+SzHUji80k
7sP/k4hNedWXf2Mfi/M1rrGz7JVDkcjaaockzGh6k9iADhimPDmQjqcG8hT2QJ2Cz1M0
TTpCwV2SfcNWcB25ueN1wGkdU459i2ouRjTHEKplYEn81DECsYx6Sjoq1NFTvg5xBAIy
SsZQPY+VpPIaitefbnBzHtSHJsGQ7exBo07wplCnoOqfvbG+mVpHnY8QqZrmnnehTIsk
djVLSX2NedKibV4PPb15S3aNrr2bJjjQ3x0a1QJmpbZrAajyO4LSb/4h+q3aJZaluMO8
BTtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=Hod5rOpUeVt943E7KgTPmIc3dGfYT/VglP7TuknDkh0=;
b=lef+mv4pnbCKNK1BSqaYs3opEFLFeeu3t4iGb/Ad/hxm3XaB5tzPFjHSjvs+n25y5/
qN5hJinvLxdCXcd8xaLDPxcJfO7DayMQ6QHipZWyY6Uz5HtRRaHWZx6McsWUuegOylBh
RbZk0yJIyy5M4t+jo+NAKFeSI9IVNoXvdKeQRwOZDFbunGKYMx4FDjhZC7mBeB3RBWVV
K2odrjwY9EZ7kE+11aESWG8LG6Df+IHKtzNuFHphLHiJfOdK1bAxPybGAsztCMg2BYGs
gIee5RrcHXm3MQObMBfHdBViimB7/MfSXXj8mENUWd0AFpiGH7isKdJ90qy3ZXrrKeRd
kmPw==
X-Gm-Message-State: AOAM533sDdWbmA30A65PJlr0gkF2KPoYpVzGhz1MJYzcxkNM66+B/jw4
YDC4YLqagaJpE2LmTuAArRrVrskwRu8XZfQPsqYsRgI2nTA=
X-Google-Smtp-Source: ABdhPJyVxRba86qZsJ/j2pxbDP/96jWglvOgDByg0l9L2dLg+Mu7vfnNizvzob5d7SynFOoolSvR8y7EzQnVawgZS+E=
X-Received: by 2002:a25:cc7:: with SMTP id 190mr19266338ybm.540.1638960401541;
Wed, 08 Dec 2021 02:46:41 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com>
<CACdvm3Oynv4gWdaGXATxc3SoYDD8kuiPq-d9F2itsmayP0qeZQ@mail.gmail.com>
In-Reply-To: <CACdvm3Oynv4gWdaGXATxc3SoYDD8kuiPq-d9F2itsmayP0qeZQ@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Wed, 8 Dec 2021 11:46:22 +0100
Message-ID: <CAPv7TjZBU2v2Nfw2_8Qz33rUWKJ=uJ7u+_5tFxjM94mk=RnmOA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000088ee7f05d2a03425"
X-Mailman-Approved-At: Wed, 08 Dec 2021 10:47:15 +0000
Subject: Re: [bitcoin-dev] [Lightning-dev] Take 2: 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: Wed, 08 Dec 2021 10:46:44 -0000
--00000000000088ee7f05d2a03425
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Jeremy,
I brought up the exact same thing at coredev, but unfortunately I came up
with a way in which the 0 sat output could still enter the UTXO set under
those rules:
- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat
- Child C1 spends the 0 sat output for a combined feerate of 1 sat per byte
and they enter the mempool as a package
- Child C2 spends the other output of P1 with a really high feerate and
enters the mempool
- Fees rise and child C1 falls out of the mempool, leaving the 0 sat output
unspent
For this to not be a problem, the 0 sat output needs to provably be the
only spendable output. As you pointed out to me a few days ago, having a
relative timelock on the other outputs would do the trick (and this happens
to be true for spacechains), but that will only be provable if all script
conditions are visible prior to spending time (ruling out p2sh and taproot,
and conflicting with standardness rules for transactions).
It's worth noting out that you can't really make a policy rule that says
the 0 sat output can't be left unspent (i.e. C1 can't be evicted without
also evicting P1), as this would not mirror economically rational behavior
for miners (they would get more fees if they evicted C1, so we must assume
they will, if the transaction ever reaches them).
This last example really points out the tricky situation we're dealing
with. In my opinion, we'd only want to relay 0 sat outputs if we can
guarantee that it's never economically profitable to mine them without them
getting spent in the same block.
Finally, here's a timestamped link to a diagram that shows where 0 sat
outputs would be helpful for spacechains (otherwise someone would have to
pay the dust up front for countless outputs):
https://youtu.be/N2ow4Q34Jeg?t=3D2556
Cheers,
Ruben
On Wed, Dec 8, 2021 at 9:35 AM Bastien TEINTURIER <bastien@acinq.fr> wrote:
> Hi Jeremy,
>
> Right now, lightning anchor outputs use a 330 sats amount. Each commitmen=
t
> transaction has two such outputs, and only one of them is spent to help t=
he
> transaction get confirmed, so the other stays there and bloats the utxo
> set.
> We allow anyone to spend them after a csv of 16 blocks, in the hope that
> someone will claim a batch of them when the fees are low and remove them
> from the utxo set. However, that trick wouldn't work with 0-value outputs=
,
> as
> no-one would ever claim them (doesn't make economical sense).
>
> We actually need to have two of them to avoid pinning: each participant i=
s
> able to spend only one of these outputs while the parent tx is unconfirme=
d.
> I believe N-party protocols would likely need N such outputs (not sure).
>
> You mention a change to the carve-out rule, can you explain it further?
> I believe it would be a necessary step, otherwise 0-value outputs for
> CPFP actually seem worse than low-value ones...
>
> Thanks,
> Bastien
>
> Le mer. 8 d=C3=A9c. 2021 =C3=A0 02:29, Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
>> Bitcoin Devs (+cc lightning-dev),
>>
>> Earlier this year I proposed allowing 0 value outputs and that was shot
>> down for various reasons, see
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/0193=
07.html
>>
>> I think that there can be a simple carve out now that package relay is
>> being launched based on my research into covenants from 2017
>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
>>
>> Essentially, if we allow 0 value outputs BUT require as a matter of
>> policy (or consensus, but policy has major advantages) that the output b=
e
>> used as an Intermediate Output (that is, in order for the transaction to=
be
>> creating it to be in the mempool it must be spent by another tx) with t=
he
>> additional rule that the parent must have a higher feerate after CPFP'in=
g
>> the parent than the parent alone we can both:
>>
>> 1) Allow 0 value outputs for things like Anchor Outputs (very good for
>> not getting your eltoo/Decker channels pinned by junk witness data using
>> Anchor Inputs, very good for not getting your channels drained by at-dus=
t
>> outputs)
>> 2) Not allow 0 value utxos to proliferate long
>> 3) It still being valid for a 0 value that somehow gets created to be
>> spent by the fee paying txn later
>>
>> Just doing this as a mempool policy also has the benefits of not
>> introducing any new validation rules. Although in general the IUTXO conc=
ept
>> is very attractive, it complicates mempool :(
>>
>> I understand this may also be really helpful for CTV based contracts
>> (like vault continuation hooks) as well as things like spacechains.
>>
>> Such a rule -- if it's not clear -- presupposes a fully working package
>> relay system.
>>
>> I believe that this addresses all the issues with allowing 0 value
>> outputs to be created for the narrow case of immediately spendable outpu=
ts.
>>
>> Cheers,
>>
>> Jeremy
>>
>> p.s. why another post today? Thank Greg
>> https://twitter.com/JeremyRubin/status/1468390561417547780
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>> <https://twitter.com/JeremyRubin>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--00000000000088ee7f05d2a03425
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Jeremy,<div><div><br></div><div>I brought up the exact =
same thing at coredev, but unfortunately I came up with a way in which the =
0 sat output could still enter the UTXO set under those rules:<br></div><di=
v><br></div><div>- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat<b=
r>- Child C1 spends the 0 sat output for a combined feerate of 1 sat per by=
te and they enter the mempool as a package<br>- Child C2 spends the other o=
utput of P1 with a really high feerate and enters the mempool<br>- Fees ris=
e and child C1 falls out of the mempool, leaving the 0 sat output unspent<b=
r></div><div><br></div><div>For this to not be a problem, the 0 sat output =
needs to provably be the only spendable output. As you pointed out to me a =
few days ago,=C2=A0having a relative timelock on the other outputs would do=
the trick (and this happens to be true for spacechains), but that will onl=
y be provable if all script conditions are visible prior to spending time (=
ruling out p2sh and taproot, and conflicting with standardness rules for tr=
ansactions).</div><div><br></div><div>It's worth noting out that you ca=
n't really make a policy rule that says the 0 sat output can't be l=
eft unspent (i.e. C1 can't be evicted without also evicting P1), as thi=
s would not mirror economically rational behavior for miners (they would ge=
t more fees if they evicted C1, so we must assume they will, if the transac=
tion ever reaches them).</div><div><br></div><div>This last example really =
points out the tricky situation we're dealing with. In my opinion, we&#=
39;d only want to relay 0 sat outputs if we can guarantee that it's nev=
er economically profitable=C2=A0to mine them without them getting spent in =
the same block.</div><div><br></div><div>Finally, here's a timestamped =
link to a diagram that shows where 0 sat outputs would be helpful for space=
chains (otherwise someone would have to pay the dust up front for countless=
outputs):</div><div><a href=3D"https://youtu.be/N2ow4Q34Jeg?t=3D2556">http=
s://youtu.be/N2ow4Q34Jeg?t=3D2556</a><br></div><div><br></div><div>Cheers,<=
/div><div>Ruben</div><div><div><br></div></div><div><br></div><div><br></di=
v></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Wed, Dec 8, 2021 at 9:35 AM Bastien TEINTURIER <<a href=3D"ma=
ilto:bastien@acinq.fr">bastien@acinq.fr</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Jeremy,<div><br>=
</div><div>Right now, lightning anchor outputs use a 330 sats amount. Each =
commitment</div><div>transaction has two such outputs, and only one of them=
is spent to help the</div><div>transaction get confirmed, so the other sta=
ys there and bloats the utxo set.</div><div>We allow anyone to spend them a=
fter a csv of 16 blocks, in the hope that</div><div>someone will claim a ba=
tch of them when the fees are low and remove them</div><div>from the utxo s=
et. However, that trick wouldn't work with 0-value outputs, as</div><di=
v>no-one would ever claim them (doesn't make economical sense).</div><d=
iv><br></div><div>We actually need to have two of them to avoid pinning: ea=
ch participant is</div><div>able to spend only one of these outputs while t=
he parent tx is unconfirmed.</div><div>I believe N-party protocols would li=
kely need N such outputs (not sure).</div><div><br></div><div>You mention a=
change to the carve-out rule, can you explain it further?</div><div>I beli=
eve it would be a necessary step, otherwise 0-value outputs for</div><div>C=
PFP actually seem worse than low-value ones...</div><div><br></div><div>Tha=
nks,</div><div>Bastien</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 8 d=C3=A9c. 2021 =C3=A0=C2=A002:=
29, Jeremy via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>>=
; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Bitcoin Devs (+c=
c lightning-dev),</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">Earlier this year I proposed allowing 0 value=
outputs and that was shot down for various=C2=A0reasons, see=C2=A0<a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019=
307.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2021-August/019307.html</a></div><div class=3D"gmail_default" styl=
e=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,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">I think that there can be =
a simple carve out now that package relay is being launched based on my res=
earch into covenants from 2017=C2=A0<a href=3D"https://rubin.io/public/pdfs=
/multi-txn-contracts.pdf" target=3D"_blank">https://rubin.io/public/pdfs/mu=
lti-txn-contracts.pdf</a>.</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">Essentially, if we allow 0 value out=
puts BUT require as a matter of policy (or consensus, but policy has major =
advantages) that the output be used as an Intermediate Output (that is, in =
order for the transaction to be creating it to be in the mempool it must be=
spent by another tx) =C2=A0with the additional rule that the parent must h=
ave a higher feerate=C2=A0after CPFP'ing the parent than the parent alo=
ne we can both:</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)">1) Allow 0 value outputs for things like Anchor=
Outputs (very good for not getting your eltoo/Decker channels pinned by ju=
nk witness data using Anchor Inputs, very good for not getting your channel=
s drained by at-dust outputs)</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) N=
ot allow 0 value utxos to proliferate long</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)">3) It still being valid for a 0 value that somehow gets created to=
be spent by the fee paying txn later</div><div class=3D"gmail_default" sty=
le=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,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">Just doing this as a memp=
ool policy also has the benefits of not introducing any new validation rule=
s. Although in general the IUTXO=C2=A0concept is very attractive, it compli=
cates mempool :(</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)">I understand this may also be really helpful f=
or CTV based contracts (like vault continuation hooks) as well as things li=
ke spacechains.</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)">Such a rule -- if it's not clear -- presupp=
oses a fully working package relay system.</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;color:rgb(0,0,0)">I believe that this =
addresses all the issues with allowing 0 value outputs to be created for th=
e narrow case of immediately spendable outputs.</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Cheers,</div><d=
iv 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" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">Jeremy</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,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-siz=
e:small;color:rgb(0,0,0)">p.s. why another post today? Thank Greg=C2=A0<a h=
ref=3D"https://twitter.com/JeremyRubin/status/1468390561417547780" target=
=3D"_blank">https://twitter.com/JeremyRubin/status/1468390561417547780</a><=
/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_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><br></div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h=
ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><=
/div></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>
_______________________________________________<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>
--00000000000088ee7f05d2a03425--
|