Bastien TEINTURIER [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-05-15 to 2023-06-07
💬 Posted a total of 124 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, RFC
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-10-18 13:02:10 UTC

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: A protocol is being designed to allow users to withdraw funds from exchanges directly into their lightning wallet with minimal on-chain activity. This requires the use of covenants to batch multiple transactions into one.
📝 Original message:
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). The
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 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 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 need
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 current
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 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 normally fixes this by exchanging signatures for a commitment
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 find
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 never
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/8902099c/attachment.html>

2023-06-09 13:04:39 UTC

- reply

📅 Original date posted:2021-12-08
📝 Original message:
Hi again AJ and list,
I have slightly re-worked your proposal, and came up with the following
(I also added the musig2 nonces for completeness):
Alice -> Bob: commitment_proposed
channel id
adaptor sigs for PTLCs to Bob in Alice's next commitment
musig nonces for Alice to spend funding tx
musig nonces for Bob to spend funding tx
Bob -> Alice: commitment_proposed
channel id
adaptor sigs for PTLCs to Alice in Bob's next commitment
musig nonces for Alice to spend funding tx
musig nonces for Bob to spend funding tx
Bob -> Alice: commitment_signed
channel id
signature for Alice to spend funding tx
sigs for Alice to spend HTLCs and PTLCs from her next commitment
Alice -> Bob: revoke_and_ack
channel id
reveal previous commitment secret
next commitment point
Alice -> Bob: commitment_signed
channel id
signature for Bob to spend funding tx
sigs for Bob to spend HTLCs and PTLCs from his next commitment
Bob -> Alice: revoke_and_ack
channel id
reveal previous commitment secret
next commitment point
I believe it's exactly the same flow of data between peers as your
proposal, but I simply split the data into several messages. Let me
know if that's incorrect or if I missed a subtlety in your proposal.
This has some small advantages:
* commitment_signed and revoke_and_ack are mostly unchanged, we just
add a new message before the commit / revoke dance. The only change
happens in commitment_signed, where the signatures for PTLC-success
transactions will actually become adaptor signatures.
* the new adaptor signatures are in commitment_proposed instead of being
in commitment_signed, which ensures that we can still have 2*483
pending (H|P)TLCs: since the message size is limited to 65kB, we would
otherwise decrease our maximum to ~2*335 with your proposal (very rough
calculation)
* the messages are now symmetrical, which may be easier to reason about
One thing to note is that we reversed the order in which participants
sign new commitments. We previously had Alice sign first, whereas now
if Alice initiates, Bob will sign the updated commitment first. This is
why we add only 0.5 RTT instead of 1 RTT compared to the current protocol.
I don't think this is an issue, but if someone sees a way to maliciously
exploit this, please share it!
I updated my article [0], people jumping on the thread now may find it
helpful to better understand this discussion.
Thanks,
Bastien
[0] https://github.com/t-bast/lightning-docs/pull/16
Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER <bastien at acinq.fr> a écrit :
> Hi AJ,
>
> I think the problem t-bast describes comes up here as well when you
>> collapse the fast-forwards (or, anytime you update the commitment
>> transaction even if you don't collapse them).
>
>
> Yes, exactly.
>
> I think doing a synchronous update of commitments to the channel state,
>> something like:
>
>
>
> Alice -> Bob: propose_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Bob
>
>
>> Bob -> Alice: agree_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Alice
>> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
>> commitment tx
>> signature for Alice to spend funding tx
>>
>> Alice -> Bob: finish_new_commitment_1
>> channel id
>> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
>> commitment tx
>> signature for Bob to spend funding tx
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> Bob -> Alice: finish_new_commitment_2
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> would work pretty well.
>
>
> I agree, this is better than my naive addition of a `remote_ptlcs_signed`
> message in both directions, and even though it changes the protocol
> messages
> it stays very close to the mechanisms we currently have.
>
> I'll spend some time specifying this in more details, to verify that we're
> not missing anything. What I really like about this proposal is that we
> can probably bundle that protocol change with `option_simplified_update`
> [0]
> without the adaptor sigs, and simply add the adaptor sigs as tlvs when we
> do PTLCs. That lets us deploy this new update protocol separately from
> PTLCs
> and ensure it also simplifies the state machine and makes other features
> such as splicing [1] and dynamic channel upgrades [2] easier.
>
> Thanks,
> Bastien
>
> [0] https://github.com/lightning/bolts/pull/867
> [1] https://github.com/lightning/bolts/pull/863
> [2] https://github.com/lightning/bolts/pull/868
>
> Le mer. 8 déc. 2021 à 10:29, Anthony Towns <aj at erisian.com.au> a écrit :
>
>> On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev
>> wrote:
>> > Alternately, fast-forwards, which avoid this because it does not change
>> commitment transactions on the payment-forwarding path.
>> > You only change commitment transactions once you have enough changes to
>> justify collapsing them.
>>
>> I think the problem t-bast describes comes up here as well when you
>> collapse the fast-forwards (or, anytime you update the commitment
>> transaction even if you don't collapse them).
>>
>> That is, if you have two PTLCs, one from A->B conditional on X, one
>> from B->A conditional on Y. Then if A wants to update the commitment tx,
>> she needs to
>>
>> 1) produce a signature to give to B to spend the funding tx
>> 2) produce an adaptor signature to authorise B to spend via X from his
>> commitment tx
>> 3) produce a signature to allow B to recover Y after timeout from his
>> commitment tx spending to an output she can claim if he cheats
>> 4) *receive* an adaptor signature from B to be able to spend the Y
>> output
>> if B posts his commitment tx using A's signature in (1)
>>
>> The problem is, she can't give B the result of (1) until she's received
>> (4) from B.
>>
>> It doesn't matter if the B->A PTLC conditional on Y is in the commitment
>> tx itself or within a fast-forward child-transaction -- any previous
>> adaptor sig will be invalidated because there's a new commitment
>> transaction, and if you allowed any way of spending without an adaptor
>> sig, B wouldn't be able to recover the secret and would lose funds.
>>
>> It also doesn't matter if the commitment transaction that A and B will
>> publish is the same or different, only that it's different from the
>> commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
>> would fix this if it were available)
>>
>> So I think this is still a relevant question, even if fast-forwards
>> make it a rare problem, that perhaps is only applicable to very heavily
>> used channels.
>>
>> (I said the following in email to t-bast already)
>>
>> I think doing a synchronous update of commitments to the channel state,
>> something like:
>>
>> Alice -> Bob: propose_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Bob
>>
>> Bob -> Alice: agree_new_commitment
>> channel id
>> adaptor sigs for PTLCs to Alice
>> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
>> commitment tx
>> signature for Alice to spend funding tx
>>
>> Alice -> Bob: finish_new_commitment_1
>> channel id
>> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
>> commitment tx
>> signature for Bob to spend funding tx
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> Bob -> Alice: finish_new_commitment_2
>> reveal old prior commitment secret
>> new commitment nonce
>>
>> would work pretty well.
>>
>> This adds half a round-trip compared to now:
>>
>> Alice -> Bob: commitment_signed
>> Bob -> Alice: revoke_and_ack, commitment_signed
>> Alice -> Bob: revoke_and_ack
>>
>> The timings change like so:
>>
>> Bob can use the new commitment after 1.5 round-trips (previously 0.5)
>>
>> Alice can be sure Bob won't use the old commitment after 2 round-trips
>> (previously 1)
>>
>> Alice can use the new commitment after 1 round-trip (unchanged)
>>
>> Bob can be sure Alice won't use the old commitment after 1.5 round-trips
>> (unchanged -- note: this is what's relevant for forwarding)
>>
>> Making the funding tx a musig setup would mean also supplying 64B
>> of musig2 nonces along with the "adaptor sigs" in one direction,
>> and providing the other side's 64B of musig2 nonces back along with the
>> (now partial) signature for spending the funding tx (a total of 256B of
>> nonce data, not 128B).
>>
>> Because it keeps both peers' commitments synchronised to a single channel
>> state, I think the same protocol should work fine with the revocable
>> signatures on a single tx approach too, though I haven't tried working
>> through the details.
>>
>> Fast forwards would then be reducing the 2 round-trip protocol to
>> update the state commitment to a 0.5 round-trip update, to reduce
>> latency when forwarding by the same amount as before (1.5 round-trips
>> to 0.5 round-trips).
>>
>> Cheers,
>> aj
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/3072a12d/attachment.html>

2023-06-09 13:04:39 UTC

- reply

📅 Original date posted:2021-12-08
📝 Original message:
Hi AJ,
I think the problem t-bast describes comes up here as well when you
> collapse the fast-forwards (or, anytime you update the commitment
> transaction even if you don't collapse them).
Yes, exactly.
I think doing a synchronous update of commitments to the channel state,
> something like:
Alice -> Bob: propose_new_commitment
> channel id
> adaptor sigs for PTLCs to Bob
> Bob -> Alice: agree_new_commitment
> channel id
> adaptor sigs for PTLCs to Alice
> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
> commitment tx
> signature for Alice to spend funding tx
>
> Alice -> Bob: finish_new_commitment_1
> channel id
> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
> commitment tx
> signature for Bob to spend funding tx
> reveal old prior commitment secret
> new commitment nonce
>
> Bob -> Alice: finish_new_commitment_2
> reveal old prior commitment secret
> new commitment nonce
>
> would work pretty well.
I agree, this is better than my naive addition of a `remote_ptlcs_signed`
message in both directions, and even though it changes the protocol messages
it stays very close to the mechanisms we currently have.
I'll spend some time specifying this in more details, to verify that we're
not missing anything. What I really like about this proposal is that we
can probably bundle that protocol change with `option_simplified_update` [0]
without the adaptor sigs, and simply add the adaptor sigs as tlvs when we
do PTLCs. That lets us deploy this new update protocol separately from PTLCs
and ensure it also simplifies the state machine and makes other features
such as splicing [1] and dynamic channel upgrades [2] easier.
Thanks,
Bastien
[0] https://github.com/lightning/bolts/pull/867
[1] https://github.com/lightning/bolts/pull/863
[2] https://github.com/lightning/bolts/pull/868
Le mer. 8 déc. 2021 à 10:29, Anthony Towns <aj at erisian.com.au> a écrit :
> On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev wrote:
> > Alternately, fast-forwards, which avoid this because it does not change
> commitment transactions on the payment-forwarding path.
> > You only change commitment transactions once you have enough changes to
> justify collapsing them.
>
> I think the problem t-bast describes comes up here as well when you
> collapse the fast-forwards (or, anytime you update the commitment
> transaction even if you don't collapse them).
>
> That is, if you have two PTLCs, one from A->B conditional on X, one
> from B->A conditional on Y. Then if A wants to update the commitment tx,
> she needs to
>
> 1) produce a signature to give to B to spend the funding tx
> 2) produce an adaptor signature to authorise B to spend via X from his
> commitment tx
> 3) produce a signature to allow B to recover Y after timeout from his
> commitment tx spending to an output she can claim if he cheats
> 4) *receive* an adaptor signature from B to be able to spend the Y output
> if B posts his commitment tx using A's signature in (1)
>
> The problem is, she can't give B the result of (1) until she's received
> (4) from B.
>
> It doesn't matter if the B->A PTLC conditional on Y is in the commitment
> tx itself or within a fast-forward child-transaction -- any previous
> adaptor sig will be invalidated because there's a new commitment
> transaction, and if you allowed any way of spending without an adaptor
> sig, B wouldn't be able to recover the secret and would lose funds.
>
> It also doesn't matter if the commitment transaction that A and B will
> publish is the same or different, only that it's different from the
> commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
> would fix this if it were available)
>
> So I think this is still a relevant question, even if fast-forwards
> make it a rare problem, that perhaps is only applicable to very heavily
> used channels.
>
> (I said the following in email to t-bast already)
>
> I think doing a synchronous update of commitments to the channel state,
> something like:
>
> Alice -> Bob: propose_new_commitment
> channel id
> adaptor sigs for PTLCs to Bob
>
> Bob -> Alice: agree_new_commitment
> channel id
> adaptor sigs for PTLCs to Alice
> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
> commitment tx
> signature for Alice to spend funding tx
>
> Alice -> Bob: finish_new_commitment_1
> channel id
> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
> commitment tx
> signature for Bob to spend funding tx
> reveal old prior commitment secret
> new commitment nonce
>
> Bob -> Alice: finish_new_commitment_2
> reveal old prior commitment secret
> new commitment nonce
>
> would work pretty well.
>
> This adds half a round-trip compared to now:
>
> Alice -> Bob: commitment_signed
> Bob -> Alice: revoke_and_ack, commitment_signed
> Alice -> Bob: revoke_and_ack
>
> The timings change like so:
>
> Bob can use the new commitment after 1.5 round-trips (previously 0.5)
>
> Alice can be sure Bob won't use the old commitment after 2 round-trips
> (previously 1)
>
> Alice can use the new commitment after 1 round-trip (unchanged)
>
> Bob can be sure Alice won't use the old commitment after 1.5 round-trips
> (unchanged -- note: this is what's relevant for forwarding)
>
> Making the funding tx a musig setup would mean also supplying 64B
> of musig2 nonces along with the "adaptor sigs" in one direction,
> and providing the other side's 64B of musig2 nonces back along with the
> (now partial) signature for spending the funding tx (a total of 256B of
> nonce data, not 128B).
>
> Because it keeps both peers' commitments synchronised to a single channel
> state, I think the same protocol should work fine with the revocable
> signatures on a single tx approach too, though I haven't tried working
> through the details.
>
> Fast forwards would then be reducing the 2 round-trip protocol to
> update the state commitment to a 0.5 round-trip update, to reduce
> latency when forwarding by the same amount as before (1.5 round-trips
> to 0.5 round-trips).
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/e5173822/attachment.html>

2023-06-09 13:01:29 UTC

- reply

📅 Original date posted:2020-11-19
📝 Original message:
Hey Rusty,
Good questions.
I think we could use additive tweaks, and they are indeed faster so it can
be worth doing.
We would replace `B(i) = HMAC256("blinded_node_id", ss(i)) * P(i)` by `B(i)
= HMAC256("blinded_node_id", ss(i)) * G + P(i)`.
Intuitively since the private key of the tweak comes from a hash function,
it should offer the same security.
But there may be dragons lurking there, I don't know how to properly
evaluate whether it's as secure (whereas the multiplicative
version is really just Sphinx, so we know it should be secure).
If we're able to use additive tweaks, we can probably indeed use x-only
pubkeys.
Even though we're not storing these on-chain, so the 1 byte saved isn't
worth much.
I'd say that if it's trivial to use them, let's do it, otherwise it's not
worth any additional effort.
Cheers,
Bastien
Le mer. 18 nov. 2020 à 06:18, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
>
> See:
>
> https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md
>
> 1. Can we use additive tweaks instead of multiplicative?
> They're slightly faster, and supported by the x-only secp API.
> 2. Can we use x-only pubkeys? It's generally trivial, and a byte
> shorter. I'm using them in offers to great effect.
>
> Thanks!
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201119/90ab3153/attachment.html>

2023-06-09 13:01:20 UTC

- reply

📅 Original date posted:2020-10-14
📝 Original message:
To be honest the current protocol can be hard to grasp at first (mostly
because it's hard to reason
about two commit txs being constantly out of sync), but from an
implementation's point of view I'm
not sure your proposals are simpler.
One of the benefits of the current HTLC state machine is that once you
describe your state as a set
of local changes (proposed by you) plus a set of remote changes (proposed
by them), where each of
these is split between proposed, signed and acked updates, the flow is
straightforward to implement
and deterministic.
The only tricky part (where we've seen recurring compatibility issues) is
what happens on
reconnections. But it seems to me that the only missing requirement in the
spec is on the order of
messages sent, and more specifically that if you are supposed to send a
`revoke_and_ack`, you must
send that first (or at least before sending any `commit_sig`). Adding test
scenarios in the spec
could help implementers get this right.
It's a bit tricky to get it right at first, but once you get it right you
don't need to touch that
code again and everything runs smoothly. We're pretty close to that state,
so why would we want to
start from scratch? Or am I missing something?
Cheers,
Bastien
Le mar. 13 oct. 2020 à 13:58, Christian Decker <decker.christian at gmail.com>
a écrit :
> I wonder if we should just go the tried-and-tested leader-based
> mechanism:
>
> 1. The node with the lexicographically lower node_id is determined to
> be the leader.
> 2. The leader receives proposals for changes from itself and the peer
> and orders them into a logical sequence of changes
> 3. The leader applies the changes locally and streams them to the peer.
> 4. Either node can initiate a commitment by proposing a `flush` change.
> 5. Upon receiving a `flush` the nodes compute the commitment
> transaction and exchange signatures.
>
> This is similar to your proposal, but does away with turn changes (it's
> always the leader's turn), and therefore reduces the state we need to
> keep track of (and re-negotiate on reconnect).
>
> The downside is that we add a constant overhead to one side's
> operations, but since we pipeline changes, and are mostly synchronous
> during the signing of the commitment tx today anyway, this comes out to
> 1 RTT for each commitment.
>
> On the other hand a token-passing approach (which I think is what you
> propose) require a synchronous token handover whenever a the direction
> of the updates changes. This is assuming I didn't misunderstand the turn
> mechanics of your proposal :-)
>
> Cheers,
> Christian
>
> Rusty Russell <rusty at rustcorp.com.au> writes:
> > Hi all,
> >
> > Our HTLC state machine is optimal, but complex[1]; the Lightning
> > Labs team recently did some excellent work finding another place the spec
> > is insufficient[2]. Also, the suggestion for more dynamic changes makes
> it
> > more difficult, usually requiring forced quiescence.
> >
> > The following protocol returns to my earlier thoughts, with cost of
> > latency in some cases.
> >
> > 1. The protocol is half-duplex, with each side taking turns; opener
> first.
> > 2. It's still the same form, but it's always one-direction so both sides
> > stay in sync.
> > update+-> commitsig-> <-revocation <-commitsig revocation->
> > 3. A new message pair "turn_request" and "turn_reply" let you request
> > when it's not your turn.
> > 4. If you get an update in reply to your turn_request, you lost the race
> > and have to defer your own updates until after peer is finished.
> > 5. On reconnect, you send two flags: send-in-progress (if you have
> > sent the initial commitsig but not the final revocation) and
> > receive-in-progress (if you have received the initial commitsig
> > not not received the final revocation). If either is set,
> > the sender (as indicated by the flags) retransmits the entire
> > sequence.
> > Otherwise, (arbitrarily) opener goes first again.
> >
> > Pros:
> > 1. Way simpler. There is only ever one pair of commitment txs for any
> > given commitment index.
> > 2. Fee changes are now deterministic. No worrying about the case where
> > the peer's changes are also in flight.
> > 3. Dynamic changes can probably happen more simply, since we always
> > negotiate both sides at once.
> >
> > Cons:
> > 1. If it's not your turn, it adds 1 RTT latency.
> >
> > Unchanged:
> > 1. Database accesses are unchanged; you need to commit when you send or
> > receive a commitsig.
> > 2. You can use the same state machine as before, but one day (when
> > this would be compulsory) you'll be able signficantly simplify;
> > you'll need to record the index at which HTLCs were changed
> > (added/removed) in case peer wants you to rexmit though.
> >
> > Cheers,
> > Rusty.
> >
> > [1] This is my fault; I was persuaded early on that optimality was more
> > important than simplicity in a classic nerd-snipe.
> > [2] https://github.com/lightningnetwork/lightning-rfc/issues/794
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201014/dcec5288/attachment.html>

2023-06-09 13:00:59 UTC

- reply

📅 Original date posted:2020-10-05
📝 Original message:
Good morning list,
It seems to me that the "funder pays all the commit tx fees" rule exists
solely for simplicity
(which was totally reasonable). I haven't been able to find much discussion
about this decision
on the mailing list nor in the spec commits.
At first glance, it's true that at the beginning of the channel lifetime,
the funder should be
responsible for the fee (it's his decision to open a channel after all).
But as time goes by and
both peers earn value from this channel, this rule becomes questionable.
We've discovered since
then that there is some risk associated with having pending HTLCs
(flood-and-loot type of attacks,
pinning, channel jamming, etc).
I think that *in some cases*, fundees should be paying a portion of the
commit-tx on-chain fees,
otherwise we may end up with a web-of-trust network where channels would
only exist between peers
that trust each other, which is quite limiting (I'm hoping we can do
better).
Routing nodes may be at risk when they *receive* HTLCs. All the attacks
that steal funds come from
the fact that a routing node has paid downstream but cannot claim the
upstream HTLCs (correct me
if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of
the HTLCs they offer
while they're pending in the commit-tx, regardless of whether they're
funder or fundee.
The simplest way to do this would be to deduce the HTLC cost (172 *
feerate) from the offerer's
main output (instead of the funder's main output, while keeping the base
commit tx weight paid
by the funder).
A more extreme proposal would be to tie the *total* commit-tx fee to the
channel usage:
* if there are no pending HTLCs, the funder pays all the fee
* if there are pending HTLCs, each node pays a proportion of the fee
proportional to the number of
HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob
pays 75% of the
commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is
redistributed.
This model uses the on-chain fee as collateral for usage of the channel. If
Alice wants to forward
HTLCs through this channel (because she has something to gain - routing
fees), she should be taking
on some of the associated risk, not Bob. Bob will be taking the same risk
downstream if he chooses
to forward.
I believe it also forces the fundee to care about on-chain feerates, which
is a healthy incentive.
It may create a feedback loop between on-chain feerates and routing fees,
which I believe is also
a good long-term thing (but it's hard to predict as there may be negative
side-effects as well).
What do you all think? Is this a terrible idea? Is it okay-ish, but not
worth the additional
complexity? Is it an amazing idea worth a lightning nobel? Please don't
take any of my claims
for granted and challenge them, there may be negative side-effects I'm
completely missing, this is
a fragile game of incentives...
Side-note: don't forget to take into account that the fees for HTLC
transactions (second-level txs)
are always paid by the party that broadcasts them (which makes sense). I
still think this is not
enough and can even be abused by fundees in some setups.
Thanks,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/521584fe/attachment.html>

2023-06-09 12:58:55 UTC

- reply

📅 Original date posted:2020-02-17
📝 Original message:
Exactly what Matt said.
I would also add that libp2p aims to be a kind of swiss-army knife for p2p
networking: that's nice for many use-cases, but when security is your main
focus, it's not.
Look at TLS: most attacks are downgrade attacks because the protocol offers
way too many options.
Protocols like Wireguard have perfectly understood this. No options, not
many configuration hooks -> small, auditable codebase.
For lightning it's the same: we prefer a very simple transport that has no
options whatsoever.
Simple to implement, simple to test, and works great in practice.
Bastien
Le lun. 17 févr. 2020 à 18:00, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
> Because writing connection logic and peer management is really not that
> complicated compared to HTLC state machines and the rest of lightning. For
> crypto, lighting does use the noise framework, though the resulting code is
> so simple (in a good way) that its super easy to just write it yourself
> instead of fighting with a dependency.
>
> Lastly, for self-respecting cryptocurrency developers,
> not-carefully-audited dependencies are security vulnerabilities that will
> expose your users’ funds. By pulling simple connection logic into a
> lighting implementation, it’s easier to test/fuzz/etc with the rest of a
> project.
>
> Matt
>
> On Feb 17, 2020, at 06:12, Alexandr Burdiyan <burdiyan at gmail.com> wrote:
>
>
> Hi everyone!
>
> Since I recently started digging into all-things-peer-to-peer, I found
> that there’s a lot of fragmentation between many different projects that
> seemingly have a lot of things in common, like networking, encoding
> standards, and etc. I suppose there’re lots of historical reasons for that.
>
> More concretely for Lightning, I wonder why it couldn’t use some existing
> open source technologies and standards, like libp2p [1] for communication,
> or various multiformats [2] standards for addresses, hashes and encodings?
>
> I do think that building and evolving common toolkits and standards for
> decentralized system like libp2p, or multiformats, or IPLD [3] could be
> something very useful for the whole community. Currently, it feels like
> everyone wants to go so fast, so there’s no time for coordination and
> consensus to build these kinds of specs. That is understandable. But I
> wonder if Lightning community ever looked at projects like libp2p and
> multiformats, or maybe is considering to implement them in lightning. Or
> maybe there was a decision of not using them for some reason that I might
> be missing.
>
> [1]: https://libp2p.io
> [2]: https://multiformats.io
> [3]: https://ipld.io
>
> Thanks!
>
> Alexandr Burdiyan
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200217/3f44b0fb/attachment.html>

2023-06-09 12:58:33 UTC

- reply

📅 Original date posted:2020-02-04
📝 Original message:
I'm a bit confused, I don't know if the implementation work you're
mentioning refers to my proposal
or yours :).
When you say `temporary id`, could you clarify whether you mean a temporary
`node_id` or `scid`?
Firstly, need to brute-force the onion against your N keys.
This is probably the part that confuses me. Are you talking about Bob or
Alice there?
Alice can easily have her `decoy_node_id` be derived from her real
`node_id`'s privacy key and the
`payment_hash` or `payment_preimage`. When she receives a payment, she
knows which `decoy_node_id`
should have been used so she doesn't need to brute-force.
That means Alice doesn't even have to change how she stores invoices. When
Alice retrieves the
invoice from her DB, if it has the `decoy_node_id` feature bit set, she
knows she needs to derive
the correct `node_id`. If it doesn't have that feature bit set, it's a
"legacy" invoice and she has
to use her real `node_id`.
Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows it's
> the same node issuing both invoices.
Same, that wouldn't work because Alice can easily detect the mismatch and
pretend she can't decrypt
the onion (the code doesn't even have to pretend: it will use the expected
`node_id` and use the
existing error paths).
Actually, that was too hasty.
Ok I think your second email came to the same conclusions and clarifies it
a bit :).
It's true that this is code where the developer may easily get confused
between keys (but it's a
lot simpler than the Sphinx or Noise implementation).
However in my opinion it's still simpler than the `scid` state management
that needs to happen at
Alice and Bob in https://github.com/lightningnetwork/lightning-rfc/pull/681
(but I would need to
implement both E2E to be able to fairly judge that).
Thanks for the feedback, I'll keep working on improving the proposal.
Bastien
Le mar. 4 févr. 2020 à 05:29, Rusty Russell <rusty at rustcorp.com.au> a écrit
:
>
> Rusty Russell <rusty at rustcorp.com.au> writes:
> > Bastien TEINTURIER <bastien at acinq.fr> writes:
> >> That's of course a solution as well. Even with that though, if Alice
opens
> >> multiple channels to each of her Bobs,
> >> she should use Tor and a different node_id each time for better
privacy.
> >
> > There are two uses for this feature (both of which I started
implementing):
> >
> > 1. Simply always use a temporary id when you have a private channel, to
> > obscure your onchain footprint. This is a nobrainer.
> >
> > 2. For an extra layer of transience, apply a new temporary id and new
> > nodeid on every invoice *which applies only for that invoice*.
> >
> > But implementing the latter securely is fraught!
> >
> > Firstly, need to brute-force the onion against your N keys. Secondly,
> > if you use a temporary key, then you *don't* end up using the HTLC to
> > pay an invoice matching that key, you *MUST* pretend you couldn't
> > decrypt the onion! This applies to all code paths between the two,
> > including parsing the TLV, etc: they must ALL return
> > WIRE_INVALID_ONION_HMAC.
> >
> > Otherwise, Mallory can get an invoice, then send malformed payments to
> > Alice using the transient key in the invoice and see if she decrypts it.
>
> Actually, that was too hasty. You can use the payment_hash as a
> fastpath:
>
> 1. Look up invoice using payment_hash.
>
> 2. If there is an invoice, and it has a temporary id associated with it,
> try using that to decrypt the onion. If that works, and the onion is
> on the final hop, and the TLV decodes, and the payment_secret is
> correct, you can go back and use this temporary key to decrypt the
onion.
> Otherwise, go back and use the normal node key.
>
> That's still quite a bit of tricky code though...
>
> Cheers,
> Rusty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/f31934c0/attachment.html>

2023-06-09 12:58:32 UTC

- reply

📅 Original date posted:2020-02-03
📝 Original message:
Hi ZmnSCPxj,
That is precisely what I am referring to, the lowest bits of the node ID
> are embedded in the SCID, which we do not want to openly reveal to Carol.
>
Got it, I wasn't understanding your point correctly. We totally agree on
that.
Though if the point is to prevent Carol from correlating different invoices
> as arising from the same payee, then my scheme fails against that.
>
IMO we should prevent Carol from correlating different invoices by using a
different node_id for each invoice.
This requires minimal changes and happens entirely payee-side (see my
initial mail).
Alice would do better to use multiple Bobs in that case.
>
That's of course a solution as well. Even with that though, if Alice opens
multiple channels to each of her Bobs,
she should use Tor and a different node_id each time for better privacy.
Cheers,
Bastien
Le lun. 3 févr. 2020 à 15:51, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
>
> > > This is relevant if we ever want to hide the node id of the last node:
> Bob could provide a symmetric
> > > encryption key to all its peers with unpublished channels, which the
> peer can XOR with its own true
> > > node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.
> >
> > I don't understand your point here. Alice cannot hide her node_id from
> Bob since the `node_id` is
> > tied to the (unannounced) channel creation.
> >
> > But this is not an issue. What Alice wants to break is the ability to
> link multiple HTLCs together
> > because they use the same `node_id`. Since Alice can use a different
> `node_id` in every invoice,
> > it's easy for her to make sure Carol cannot tie those HTLCs together.
>
> That is precisely what I am referring to, the lowest bits of the node ID
> are embedded in the SCID, which we do not want to openly reveal to Carol.
> Though if the point is to prevent Carol from correlating different
> invoices as arising from the same payee, then my scheme fails against that.
>
> >
> > In order to hide from Bob, the best Alice can do is use a different
> `node_id` for each channel she
> > opens to Bob and use Tor. This way Bob cannot know that node_id_1 and
> node_id_2 both belong to Alice.
> > I don't think we can do better than that.
>
> Alice would do better to use multiple Bobs in that case.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200203/acea682e/attachment-0001.html>

2023-06-09 12:58:32 UTC

- reply

📅 Original date posted:2020-02-03
📝 Original message:
Thanks for the feedback and discussion. Here are some more comments.
This is relevant if we ever want to hide the node id of the last node: Bob
> could provide a symmetric
> encryption key to all its peers with unpublished channels, which the peer
> can XOR with its own true
> node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.
I don't understand your point here. Alice cannot hide her node_id from Bob
since the `node_id` is
tied to the (unannounced) channel creation.
But this is not an issue. What Alice wants to break is the ability to link
multiple HTLCs together
because they use the same `node_id`. Since Alice can use a different
`node_id` in every invoice,
it's easy for her to make sure Carol cannot tie those HTLCs together.
In order to hide from Bob, the best Alice can do is use a different
`node_id` for each channel she
opens to Bob and use Tor. This way Bob cannot know that node_id_1 and
node_id_2 both belong to Alice.
I don't think we can do better than that.
I really don't want a special marker on Carol; she needs to just pay like
> normal.
I agree that this would be the ideal outcome (and my current proposal
doesn't achieve that, but I'm
hoping I can improve it to achieve that). Do note that even though my
current proposal requires
a code update from Carol, the code-change would be very small. Adding
support for `payment_secret`
did require a change on Carol to improve security; I'm hoping that a small
enough code-change with
a big enough privacy improvement would eventually be supported by all three
implementations (and
then find its way inside wallets).
I must admit I'm a bit turned off by the state management required by your
proposal. I'm afraid it
may be complex to get right, or be subject to fingerprinting and wouldn't
result in the privacy
gain we're hoping.
I think this really needs to be cheap for Bob; if Bob can be DoS-ed by
offering this feature, I
don't think the Bobs out there will activate it.
I really feel some cryptography trick can allow us to find a solution that
requires no more than a
shared secret to be kept between Alice and Bob, and no
synchronization/state management.
I'd like to explore this option further.
Cheers,
Bastien
Le lun. 3 févr. 2020 à 07:51, m.a.holden via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> > (I'm seeking a clever way that Bob can assign them and trivially tell
> > which ID is assigned to which peer, but I can't figure it out, so I
> > guess Bob keeps a mapping and restricts each peer to 256 live scids?).
>
> Hi Rusty.
>
> Here's a potential way for Alice and Bob to agree a set of 256 scids
> without any additional messages or changes to existing messages beyond a
> feature flag and a flag in open_channel, but comes with a computational
> cost.
>
> Alice and Bob agree on a random integer `r`. This could be negotiated on
> `open_channel`, but we shouldn't need to send additional information
> because we already have a random integer we can use: the
> `temporary_channel_id`. This is not known to anybody besides Alice and Bob.
>
> When a channel is locked, Bob computes n=256 scids, using something
> approximating `concat(n, trunc_bytes(sha256(ec_mult(2^n*r, Q)), 7))`, where
> `Q` is Alice's public key for the channel funding transaction.
>
> The chance of scid collisions between channels is 2^56, which is probably
> no cause for concern.
>
> Instead of keeping a map of 256 scids for each channel, Bob can use a
> cuckoo filter for efficiency. The filter can be used for a quick membership
> test and also as an associative map from scids to channels. It can also
> support scid deletion in the event of channel closure (at the cost of
> recomputing 256 ec_mults again).
>
> So when Bob receives a new HTLC to forward, he tests it against his cuckoo
> filter and retreives a candidate set of possible channels to which it may
> refer. For each channel, he takes the most significant byte of the scid as
> `m` and performs `trunc_bytes(sha256(ec_mult(2^m*r, Q)), 7)` and tests the
> least-significant 7 bytes of the result against the scid.
>
> Alice does not need to keep all of the scids she may use for invoices
> because they can be computed on the fly, but she will need to keep a copy
> of the `temporary_channel_id`.
>
> In the reverse direction of Alice forwarding HTLCs to Bob, Bob's public
> key for the funding transaction is used instead.
>
> Regards,
> Mark Holden
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200203/46cc458b/attachment.html>

2023-06-09 12:57:08 UTC

- reply

📅 Original date posted:2019-11-22
📝 Original message:
While I agree with most of your points, I think there are subtleties to
explore before
completely rejecting the idea.
every use of proof-of-work today (other than to power Bitcoin itself, as
> Bitcoin cannot support itself) can instead be done by using Bitcoins to
> impose this economic cost.
>
That is philosophically true, but the complexity of integrating that small
PoW into Lightning
is much lower than the complexity of integrating **fair, un-gameable**
upfront payments.
And not all PoW is born equal: there are a lot of PoW schemes that have
different trade-offs
than Bitcoin mining (think ASIC-resistance such as variants of Cuckoo
Cycle).
Another key point is that creating ASICs for this PoW is fundamentally
different from creating
ASICs for mining a crypto-currency. Solving this PoW doesn't earn you any
money: it merely
allows you to spam to temporarily disrupt the network.
Since this PoW isn't used in any consensus, we can change the spam PoW
algorithm anytime
we want, making all previous ASICs obsolete.
So it's not obvious to me that anyone would find it viable to invest in
creating such ASICs.
As hardware specialization for the specific Lightning-Network-proof-of-work
> arises, we will find that to practically limit spam, intermediate nodes
> will have to increase and increase the threshold for accepting
> proof-of-work, as spammers are going to switch to the more-specialized
> hardware.
>
That's where I think it can be more subtle than what you describe (I may be
wrong though as
predicting future behavior is hard).
Since I'm ruling out ASICs, we're only dealing with "normal" hardware
bottlenecks (cpu/ram).
That means attackers are not playing at a completely different scale than
normal users.
The cost for attackers to generate an amount of spam mimicking N normal
users will then be
somewhat linear in N (to be investigated further).
That's exactly the same result as upfront payments, where an attacker can
still spam like
he's N users if he's ready to pay a cost linear in N.
I'm slightly playing devil's advocate for the PoW proposal because I think
it's worth exploring
more, even if we eventually abandon it. Maybe you're right and it won't be
as effective to
fight spam as upfront payments: but right now with the arguments I've seen
on this thread,
I'm not yet convinced of that.
Cheers,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191122/32cc41a8/attachment.html>

2023-06-09 12:57:07 UTC

- reply

📅 Original date posted:2019-11-22
📝 Original message:
I think there's another alternative than upfront payments to prevent spam,
which is maybe less
controversial (but potentially less effective as well - to be investigated).
Why not adapt what has been done with email spam and PoW/merkle puzzles?
The high-level idea would be that the sender must solve a small PoW puzzle *for
each intermediate *
*node *and communicate the solution in the onion.
There are many ways we could do that (a new field in each intermediate hop,
grinding an HMAC
prefix, etc) so before going into specifics I only wanted to submit the
high-level idea.
What's neat with this is that it's simple, doesn't leak any privacy, and
avoids having to create a
node reputation system.
We fight spam by forcing the sender to use some resources (instead of sats).
Maybe this idea has already been proposed and broken, if that's the case
I'd love to see the
discussion if someone can surface it.
Cheers,
Bastien
Le lun. 11 nov. 2019 à 00:32, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> Anthony Towns <aj at erisian.com.au> writes:
> > On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
> >> Anthony Towns <aj at erisian.com.au> writes:
> >> [ Snip summary, which is correct ]
> >
> > Huzzah!
> >
> > This correlates all the hops in a payment when the route reaches its end
> > (due to the final preimage getting propogated back for everyone to
> justify
> > the funds they claim). Maybe solvable by converting from hashes to ECC
> > as the trapdoor function?
>
> I hadn't thought of this, but yes, once we've eliminated the trivial
> preimage correlation w/scriptless scripts it'd be a shame to reintroduce
> it here.
>
> We need an accumulator with some strange properties though:
>
> 1. Alice provides tokens and a base accumulator.
> 2. Bob et. al can add these tokens to the accumulator.
> 3. They can tell if invalid tokens have been added to the accumulator.
> 4. They can tell how many tokens (alt: each token has a value and they
> can tell the value sum) have been added.
> 5. They can't tell what tokens have been added (unless they know all
> the tokens, which is trivial).
>
> Any ideas?
>
> > The refund amount propogating back also reveals the path, probably.
> > Could that be obfusticated by somehow paying each intermediate node
> > both as the funds go out and come back, so the refund decreases on the
> > way back?
> >
> > Oh, can we make the amounts work like the onion, where it stays constant?
> > So:
> >
> > Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets
> > 400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.
> >
> > Success:
> > Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
> > Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
> > Carol forwards 1500 msat to Dave (-1500, 0, 0, +1500)
> > Dave refunds 1200 msat to Carol (-1500, 0, +1200, +300)
> > Carol refunds 800 msat to Bob (-1500, +800, +400, +300)
> > Bob refunds 100 msat to Alice (-1400, +700, +400, +300)
>
> Or, on success, upfront payment is fully refunded or not refunded at all
> (since they get paid by normal fees)? Either way, no data leak for that
> case.
>
> > Clean routing failure at Carol/Dave:
> > Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
> > Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
> > Carol says Dave's not talking
> > Carol refunds 1100 msat to Bob (-1500, +1100, +400, 0)
> > Bob refunds 400 msat to Alice (-1100, +700, +400, 0)
> >
> > I think that breaks the correlation pretty well, so you just need a
> > decent way of obscuring path length?
>
> I don't see how this breaks correlation?
>
> > In the uncooperative routing failure case, I wonder if using an ECC
> > trapdoor and perhaps scriptless scripts, you could make it so Carol
> > doesn't even get an updated state without revealing the preimage...
>
> I'm not sure. We can make it so Carol has Bob's preimage(s), etc, so
> that the node which fails doesn't get paid. I initially thought this
> would just make people pair up (fake) nodes, but it's probably not worth
> it since their path would be less-selected in that case.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191122/c0045b8d/attachment.html>

2023-06-09 12:40:21 UTC

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Hi Rusty,
On the eclair side, we instead send `funding_locked` as soon as we
see the funding tx in the mempool.
But I think your proposal would work as well.
We may want to defer sending `announcement_signatures` until
after the funding tx has been confirmed? What `min_depth` should
we use here? Should we keep a non-zero value in `accept_channel`
or should it be zero?
Cheers,
Bastien
Le mar. 29 juin 2021 à 07:34, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> Hi all!
>
> John Carvalo recently pointed out that not every implementation
> accepts zero-conf channels, but they are useful. Roasbeef also recently
> noted that they're not spec'd.
>
> How do you all do it? Here's a strawman proposal:
>
> 1. Assign a new feature bit "I accept zeroconf channels".
> 2. If both negotiate this, you can send update_add_htlc (etc) *before*
> funding_locked without the peer getting upset.
> 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel
> unless they have explicit reason to trust that node (they can still
> send *out* that channel, because that's not their problem!).
>
> It's a pretty simple change, TBH (this zeroconf feature would also
> create a new set of channel_types, altering that PR).
>
> I can draft something this week?
>
> Thanks!
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210629/a9f7eb76/attachment.html>