path: root/28/80e709c5fe3abf1d37d38e9dfffb18eb127ec8

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&#39;s worth noting out that you ca=
n&#39;t really make a policy rule that says the 0 sat output can&#39;t be l=
eft unspent (i.e. C1 can&#39;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&#39;re dealing with. In my opinion, we&#=
39;d only want to relay 0 sat outputs if we can guarantee that it&#39;s nev=
er economically profitable=C2=A0to mine them without them getting spent in =
the same block.</div><div><br></div><div>Finally, here&#39;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 &lt;<a href=3D"ma=
ilto:bastien@acinq.fr">bastien@acinq.fr</a>&gt; 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&#39;t work with 0-value outputs, as</div><di=
v>no-one would ever claim them (doesn&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; 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&#39;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&#39;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--