From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 76634C0032 for ; Thu, 19 Oct 2023 07:35:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 3F74D60E2E for ; Thu, 19 Oct 2023 07:35:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3F74D60E2E Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=acinq.fr header.i=@acinq.fr header.a=rsa-sha256 header.s=google header.b=GJBTkiRm X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 H3UBTSlyFk81 for ; Thu, 19 Oct 2023 07:35:38 +0000 (UTC) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1C6A960BD2 for ; Thu, 19 Oct 2023 07:35:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1C6A960BD2 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-507a3b8b113so6876400e87.0 for ; Thu, 19 Oct 2023 00:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acinq.fr; s=google; t=1697700936; x=1698305736; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YyuAl06DOLUDY6QmHxOYv050jrOXopuwEw0vN08lMY0=; b=GJBTkiRmJ0UgDKDif0YsDKJ02cv5IpnjiJ0pAHDCT5Ai6fYwOq2IizkLsPT1Pvulan 1VlDLnHv63HhgDf79zjCHXa+InHCyRkmG6JBRD7qML5CmHidfuvVFy/QOPz3mxEUMiql zJPS73I1O2VivacrZd3LoPzHRNSAzcQel8dkaHGgXmMtNGHcPJObkT4aHbUzHyvuzXHl bX/xBx++IMfQYzwXnNESZhF9aTepR19dF8ugWS6sYn8nK6phjcNUXLNJI5M/MbqjqdeX fDMcnjZ7Ic2PWntUHytudJfeRX8fv4+dd3uU0GemRgm8dKKg4raZhHNMB9wkNMjZJMhr 5Zwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697700936; x=1698305736; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YyuAl06DOLUDY6QmHxOYv050jrOXopuwEw0vN08lMY0=; b=ESJFcc/P7V0TArMR+2dCvhWZDkswZs2uBPNep/xXAkldu5nmpSCLSTXWeCqPHdJlOo CksM/i3iJGydNNn3nI8Wi0VE2ZF9iWvlx2Wlkzwf7XISd78/VosLsEckpJr0JBdW1qDY Mcggfm3aAFsDzefGdjdYzdmzDd0cmjiAbblfuAwIYnrK6H1IVHYSJyg2ePPC+rFz+3zM Gc22hjhdd79TLfLAbL6CRnIFK+957q7IeiL22aFW9+hQFTr2FSMAniBfOAkrTzPyO2MM vRrqHl5mCvnxFvJej++qr0Y1v8gfhFEXsQup0jrCdY4EGnbDagCdTUsTONKy10p+bRp3 uzqg== X-Gm-Message-State: AOJu0YwB5JMNiTvm1DPLsYfBL5ItD+6GNJHCEYZi6uB/JTXmqmXQWeLC lO07OFw8wEnl2kXzjC4x/Ul1R0K6FjfUYIZksctU9g== X-Google-Smtp-Source: AGHT+IGzF137Xs/CHuw0Ma2paBXNxm4b7Jn9WLarTqvCGaCaS/vcrSi2VklEbOjFZfFtP7kLz4xYRoCxR3IO+Kyv338= X-Received: by 2002:a19:a418:0:b0:507:968d:a301 with SMTP id q24-20020a19a418000000b00507968da301mr762752lfc.55.1697700935232; Thu, 19 Oct 2023 00:35:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bastien TEINTURIER Date: Thu, 19 Oct 2023 09:35:23 +0200 Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="0000000000002e170906080ccd38" X-Mailman-Approved-At: Thu, 19 Oct 2023 08:47:02 +0000 Cc: Bitcoin Protocol Discussion , "lightning-dev\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2023 07:35:40 -0000 --0000000000002e170906080ccd38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, > If I'm correct, two users can cooperate maliciously against the batch > withdrawal transactions by re-signing a CPFP from 2-of-2 and > broadcasting the batch withdrawal as a higher-feerate package / high > fee package and then evicting out the CPFP. Yes, they can, and any user could also double-spend the batch using a commit tx spending from the previous funding output. Participants must expect that this may happen, that's what I mentioned previously that you cannot use 0-conf on that splice transaction. But apart from that, it acts as a regular splice: participants must watch for double-spends (as discussed in the previous messages) while waiting for confirmations. > If the batch withdrawal has been signed with 0-fee thanks to the > nversion=3D3 policy exemption, it will be evicted out of the mempool. > A variant of a replacement cycling attack. I don't think this should use nVersion=3D3 and pay 0 fees. On the contrary this is a "standard" transaction that should use a reasonable feerate and nVersion=3D2, that's why I don't think this comment applies. Cheers, Bastien Le mer. 18 oct. 2023 =C3=A0 20:04, Antoine Riard = a =C3=A9crit : > Hi Bastien, > > Thanks for the answer. > > If I understand correctly the protocol you're describing you're aiming to > enable batched withdrawals where a list of users are being sent funds fro= m > an exchange directly in a list of channel funding outputs ("splice-out"). > Those channels funding outputs are 2-of-2, between two lambda users or e.= g > a lambda user and a LSP. > > If I'm correct, two users can cooperate maliciously against the batch > withdrawal transactions by re-signing a CPFP from 2-of-2 and broadcasting > the batch withdrawal as a higher-feerate package / high fee package and > then evicting out the CPFP. > > If the batch withdrawal has been signed with 0-fee thanks to the > nversion=3D3 policy exemption, it will be evicted out of the mempool. A > variant of a replacement cycling attack. > > I think this more or less matches the test I'm pointing to you which is o= n > non-deployed package acceptance code: > > https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d= 72f1efcf > > Please correct me if I'm wrong or missing assumptions. Agree with you on > the assumptions that the exchange does not have an incentive to > double-spend its own withdrawal transactions, or if all the batched fundi= ng > outputs are shared with a LSP, malicious collusion is less plausible. > > Best, > Antoine > > Le mer. 18 oct. 2023 =C3=A0 15:35, Bastien TEINTURIER = a > =C3=A9crit : > >> Hey Z-man, Antoine, >> >> Thank you for your feedback, responses inline. >> >> z-man: >> >> > Then if I participate in a batched splice, I can disrupt the batched >> > splice by broadcasting the old state and somehow convincing miners to >> > confirm it before the batched splice. >> >> Correct, I didn't mention it in my post but batched splices cannot use >> 0-conf, the transaction must be confirmed to remove the risk of double >> spends using commit txs associated with the previous funding tx. >> >> But interestingly, with the protocol I drafted, the LSP can finalize and >> broadcast the batched splice transaction while users are offline. With a >> bit of luck, when the users reconnect, that transaction will already be >> confirmed so it will "feel 0-conf". >> >> Also, we need a mechanism like the one you describe when we detect that >> a splice transaction has been double-spent. But this isn't specific to >> batched transactions, 2-party splice transactions can also be double >> spent by either participant. So we need that mechanism anyway? The spec >> doesn't have a way of aborting a splice after exchanging signatures, but >> you can always do it as an RBF operation (which actually just does a >> completely different splice). This is what Greg mentioned in his answer. >> >> > part of the splice proposal is that while a channel is being spliced, >> > it should not be spliced again, which your proposal seems to violate. >> >> The spec doesn't require that, I'm not sure what made you think that. >> While a channel is being spliced, it can definitely be spliced again as >> an RBF attempt (this is actually a very important feature), which double >> spends the other unconfirmed splice attempts. >> >> ariard: >> >> > It is uncertain to me if secure fee-bumping, even with future >> > mechanisms like package relay and nversion=3D3, is robust enough for >> > multi-party transactions and covenant-enable constructions under usual >> > risk models. >> >> I'm not entirely sure why you're bringing this up in this context... >> I agree that we most likely cannot use RBF on those batched transactions >> we will need to rely on CPFP and potentially package relay. But why is >> it different from non-multi-party transactions here? >> >> > See test here: >> > >> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43= d72f1efcf >> >> I'd argue that this is quite different from the standard replacement >> cycling attack, because in this protocol wallet users can only >> unilaterally double-spend with a commit tx, on which they cannot set >> the feerate. The only participant that can "easily" double-spend is >> the exchange, and they wouldn't have an incentive to here, users are >> only withdrawing funds, there's no opportunity of stealing funds? >> >> Thanks, >> Bastien >> >> Le mar. 17 oct. 2023 =C3=A0 21:10, Antoine Riard a >> =C3=A9crit : >> >>> Hi Bastien, >>> >>> > The naive way of enabling lightning withdrawals is to make the user >>> > provide a lightning invoice that the exchange pays over lightning. Th= e >>> > issue is that in most cases, this simply shifts the burden of making = an >>> > on-chain transaction to the user's wallet provider: if the user doesn= 't >>> > have enough inbound liquidity (which is likely), a splice transaction >>> > will be necessary. If N users withdraw funds from an exchange, we mos= t >>> > likely will end up with N separate splice transactions. >>> >>> It is uncertain to me if secure fee-bumping, even with future mechanism= s >>> like package relay and nversion=3D3, is robust enough for multi-party >>> transactions and covenant-enable constructions under usual risk models. >>> >>> See test here: >>> >>> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f4= 3d72f1efcf >>> >>> Appreciated expert eyes of folks understanding both lightning and core >>> mempool on this. >>> There was a lot of back and forth on nversion=3D3 design rules, though = the >>> test is normally built on glozow top commit of the 3 Oct 2023. >>> >>> Best, >>> Antoine >>> >>> Le mar. 17 oct. 2023 =C3=A0 14:03, Bastien TEINTURIER a >>> =C3=A9crit : >>> >>>> Good morning list, >>>> >>>> I've been trying to design a protocol to let users withdraw funds from >>>> exchanges directly into their lightning wallet in an efficient way >>>> (with the smallest on-chain footprint possible). >>>> >>>> I've come to the conclusion that this is only possible with some form = of >>>> covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). Th= e >>>> goal of this post is to explain why, and add this usecase to the list = of >>>> useful things we could do if we had covenants (insert "wen APO?" meme)= . >>>> >>>> The naive way of enabling lightning withdrawals is to make the user >>>> provide a lightning invoice that the exchange pays over lightning. The >>>> issue is that in most cases, this simply shifts the burden of making a= n >>>> on-chain transaction to the user's wallet provider: if the user doesn'= t >>>> have enough inbound liquidity (which is likely), a splice transaction >>>> will be necessary. If N users withdraw funds from an exchange, we most >>>> likely will end up with N separate splice transactions. >>>> >>>> Hence the idea of batching those into a single transaction. Since we >>>> don't want to introduce any intermediate transaction, we must be able >>>> to create one transaction that splices multiple channels at once. The >>>> issue is that for each of these channels, we need a signature from the >>>> corresponding wallet user, because we're spending the current funding >>>> output, which is a 2-of-2 multisig between the wallet user and the >>>> wallet provider. So we run into the usual availability problem: we nee= d >>>> signatures from N users who may not be online at the same time, and if >>>> one of those users never comes online or doesn't complete the protocol= , >>>> we must discard the whole batch. >>>> >>>> There is a workaround though: each wallet user can provide a signature >>>> using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their curren= t >>>> funding output to create a new funding output with the expected amount= . >>>> This lets users sign *before* knowing the final transaction, which the >>>> exchange can create by batching pairs of inputs/outputs. But this has >>>> a fatal issue: at that point the wallet user has no way of spending th= e >>>> new funding output (since it is also a 2-of-2 between the wallet user >>>> and the wallet provider). The wallet provider can now blackmail the us= er >>>> and force them to pay to get their funds back. >>>> >>>> Lightning normally fixes this by exchanging signatures for a commitmen= t >>>> transaction that sends the funds back to their owners *before* signing >>>> the parent funding/splice transaction. But here that is impossible, >>>> because we don't know yet the `txid` of the batch transaction (that's >>>> the whole point, we want to be able to sign before creating the batch) >>>> so we don't know the new `prevout` we should spend from. I couldn't fi= nd >>>> a clever way to work around that, and I don't think there is one (but >>>> I would be happy to be wrong). >>>> >>>> With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange >>>> anyprevout signatures for the commitment transaction, and they will be >>>> valid to spend from the batch transaction. We are safe from signature >>>> reuse, because funding keys are rotated at each splice so we will neve= r >>>> create another output that uses the same 2-of-2 script. >>>> >>>> I haven't looked at other forms of covenants, but most of them likely >>>> address this problem as well. >>>> >>>> Cheers, >>>> Bastien >>>> _______________________________________________ >>>> Lightning-dev mailing list >>>> Lightning-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>>> >>> --0000000000002e170906080ccd38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

> If I'm correct, two users can = cooperate maliciously against the batch
> withdrawal transactions by = re-signing a CPFP from 2-of-2 and
> broadcasting the batch withdrawal= as a higher-feerate package / high
> fee package and then evicting o= ut the CPFP.

Yes, they can, and any user could also double-spend the= batch using a
commit tx spending from the previous funding output. Part= icipants must
expect that this may happen, that's what I mentioned p= reviously that
you cannot use 0-conf on that splice transaction. But apa= rt from that,
it acts as a regular splice: participants must watch for d= ouble-spends
(as discussed in the previous messages) while waiting for c= onfirmations.

> If the batch withdrawal has been signed with 0-fe= e thanks to the
> nversion=3D3 policy exemption, it will be evicted o= ut of the mempool.
> A variant of a replacement cycling attack.
I don't think this should use nVersion=3D3 and pay 0 fees. On the con= trary
this is a "standard" transaction that should use a reaso= nable feerate
and nVersion=3D2, that's why I don't think this co= mment applies.

Cheers,
Bastien

Le=C2=A0mer. 18 oct. 2023 =C3= =A0=C2=A020:04, Antoine Riard <antoine.riard@gmail.com> a =C3=A9crit=C2=A0:
Hi Bastien,

=
Thanks for the answer.

If I understand = correctly the protocol=C2=A0you're describing=C2=A0you're aiming to= enable batched withdrawals where a list of users are being sent funds from= an exchange directly in a list of channel funding outputs ("splice-ou= t"). Those channels funding outputs are 2-of-2, between two lambda use= rs or e.g a lambda user and a LSP.

If I'm corr= ect, two users can cooperate maliciously against the batch withdrawal trans= actions by re-signing a CPFP from 2-of-2 and broadcasting the batch withdra= wal as a higher-feerate package / high fee package and then evicting out th= e CPFP.=C2=A0

If the batch withdrawal has been sig= ned with 0-fee thanks to the nversion=3D3 policy exemption, it will be evic= ted out of the=C2=A0mempool. A variant of a replacement cycling attack.

I think this more or less=C2=A0matches the test I'= ;m pointing to you which is on non-deployed package acceptance code:
<= div>https://github.com/ariard/bitcoin/= commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf

Please correct me if I'm wrong or missing assumptions. Agree with= you on the assumptions that the exchange does not have an incentive to dou= ble-spend its own withdrawal transactions, or if all the batched funding ou= tputs are shared with a LSP, malicious collusion is less plausible.

Best,
Antoine

Le=C2=A0mer. 18 oct. 2023 = =C3=A0=C2=A015:35, Bastien TEINTURIER <bastien@acinq.fr> a =C3=A9crit=C2=A0:
=
Hey Z-ma= n, Antoine,

Thank you for your feedback, responses inline.

z-= man:

> Then if I participate in a batched splice, I can disrupt t= he batched
> splice by broadcasting the old state and somehow convinc= ing miners to
> confirm it before the batched splice.

Correct,= I didn't mention it in my post but batched splices cannot use
0-con= f, the transaction must be confirmed to remove the risk of double
spends= using commit txs associated with the previous funding tx.

But inter= estingly, with the protocol I drafted, the LSP can finalize and
broadcas= t the batched splice transaction while users are offline. With a
bit of = luck, when the users reconnect, that transaction will already be
confirm= ed so it will "feel 0-conf".

Also, we need a mechanism lik= e the one you describe when we detect that
a splice transaction has been= double-spent. But this isn't specific to
batched transactions, 2-pa= rty splice transactions can also be double
spent by either participant. = So we need that mechanism anyway? The spec
doesn't have a way of abo= rting a splice after exchanging signatures, but
you can always do it as = an RBF operation (which actually just does a
completely different splice= ). This is what Greg mentioned in his answer.

> part of the splic= e proposal is that while a channel is being spliced,
> it should not = be spliced again, which your proposal seems to violate.

The spec doe= sn't require that, I'm not sure what made you think that.
While = a channel is being spliced, it can definitely be spliced again as
an RBF= attempt (this is actually a very important feature), which double
spend= s the other unconfirmed splice attempts.

ariard:

> It is u= ncertain to me if secure fee-bumping, even with future
> mechanisms l= ike package relay and nversion=3D3, is robust enough for
> multi-part= y transactions and covenant-enable constructions under usual
> risk m= odels.

I'm not entirely sure why you're bringing this up in = this context...
I agree that we most likely cannot use RBF on those batc= hed transactions
we will need to rely on CPFP and potentially package re= lay. But why is
it different from non-multi-party transactions here?
=
> See test here:
> https:= //github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf=

I'd argue that this is quite different from the standard re= placement
cycling attack, because in this protocol wallet users can only=
unilaterally double-spend with a commit tx, on which they cannot setthe feerate. The only participant that can "easily" double-spend= is
the exchange, and they wouldn't have an incentive to here, users= are
only withdrawing funds, there's no opportunity of stealing fund= s?

Thanks,
Bastien

Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A021:10= , Antoine Riard <antoine.riard@gmail.com> a =C3=A9crit=C2=A0:
Hi Bastien,
=
> The naive way of enabling lightning withdrawals is to m= ake the user
> provide a lightning invoice that the exchange pays ove= r lightning. The
> issue is that in most cases, this simply shifts th= e burden of making an
> on-chain transaction to the user's wallet= provider: if the user doesn't
> have enough inbound liquidity (w= hich is likely), a splice transaction
> will be necessary. If N users= withdraw funds from an exchange, we most
> likely will end up with N= separate splice transactions.

It is uncertain= to me if secure fee-bumping, even with future mechanisms like package rela= y and=C2=A0nversion=3D3, is robust enough for multi-party transactions and = covenant-enable constructions under usual risk models.

=
See test here:



Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A014:03, Bastien = TEINTURIER <bastie= n@acinq.fr> a =C3=A9crit=C2=A0:
Good morning list,

I've = been trying to design a protocol to let users withdraw funds from
exchan= ges directly into their lightning wallet in an efficient way
(with the s= mallest on-chain footprint possible).

I've come to the conclusio= n that this is only possible with some form of
covenants (e.g. `SIGHASH_= ANYPREVOUT` would work fine in this case). The
goal of this post is to e= xplain why, and add this usecase to the list of
useful things we could d= o if we had covenants (insert "wen APO?" meme).

The naive = way of enabling lightning withdrawals is to make the user
provide a ligh= tning invoice that the exchange pays over lightning. The
issue is that i= n most cases, this simply shifts the burden of making an
on-chain transa= ction to the user's wallet provider: if the user doesn't
have en= ough inbound liquidity (which is likely), a splice transaction
will be n= ecessary. If N users withdraw funds from an exchange, we most
likely wil= l end up with N separate splice transactions.

Hence the idea of batc= hing those into a single transaction. Since we
don't want to introdu= ce any intermediate transaction, we must be able
to create one transacti= on that splices multiple channels at once. The
issue is that for each of= these channels, we need a signature from the
corresponding wallet user,= because we're spending the current funding
output, which is a 2-of-= 2 multisig between the wallet user and the
wallet provider. So we run in= to the usual availability problem: we need
signatures from N users who m= ay not be online at the same time, and if
one of those users never comes= online or doesn't complete the protocol,
we must discard the whole = batch.

There is a workaround though: each wallet user can provide a = signature
using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends thei= r current
funding output to create a new funding output with the expecte= d amount.
This lets users sign *before* knowing the final transaction, w= hich the
exchange can create by batching pairs of inputs/outputs. But th= is has
a fatal issue: at that point the wallet user has no way of spendi= ng the
new funding output (since it is also a 2-of-2 between the wallet = user
and the wallet provider). The wallet provider can now blackmail the= user
and force them to pay to get their funds back.

Lightning no= rmally fixes this by exchanging signatures for a commitment
transaction = that sends the funds back to their owners *before* signing
the parent fu= nding/splice transaction. But here that is impossible,
because we don= 9;t know yet the `txid` of the batch transaction (that's
the whole p= oint, we want to be able to sign before creating the batch)
so we don= 9;t know the new `prevout` we should spend from. I couldn't find
a c= lever way to work around that, and I don't think there is one (but
I= would be happy to be wrong).

With `SIGHASH_ANYPREVOUT`, this is imm= ediately fixed: we can exchange
anyprevout signatures for the commitment= transaction, and they will be
valid to spend from the batch transaction= . We are safe from signature
reuse, because funding keys are rotated at = each splice so we will never
create another output that uses the same 2-= of-2 script.

I haven't looked at other forms of covenants, but m= ost of them likely
address this problem as well.

Cheers,
Basti= en
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev
--0000000000002e170906080ccd38--