Re: [Lightning-dev] PoDLEs revisited
On Fri, Jan 29, 2021 at 10:51 AM Rusty Russell wrote: > Less true after taproot though? > The heuristic from [1] is not affected by Taproot. Taproot will be helpful for keeping private channels private against the method in [2] though. > [1] https://arxiv.org/abs/2007.00764 > > [2] https://arxiv.org/pdf/2003.12470.pdf > > [3] https://graphsense.info/ > > > > I am told there is a new revision of [1] coming out any day now that will > > present a few more tricks and have contributions directly from a > scientist > > at Chainalsysis (the company). > > I'll add to my reading list (or wait for one of my colleagues to provide > the TL;DR!). > > Let me TL;DR quickly the core idea quickly as it's not too difficult to grasp. 1. You are node n_1 2. You fund a public channel to node n_2 called c1 3. You use the change to fund a public channel to node n_3 called c2 4. The network sees that n_1 is involved in both c_1 and c_2. They're both public channels so the channel_id gives away the on-chain funding utxo. Everyone can conclude that the owner of n_1 was also the funder of both and therefore owns the change output of the funding of c_2. Consider a variant of this heuristic where instead of using funding change they use the output of a cooperative close of c_1 to to fund c_2. By the same reasoning you can identify the owner of n_1 funded the channel but you can also now know that n_2 is the owner of the other utxo of the close of c_1. The point of this is if you are a node that is churning UTXOs from the funding change or the closing UTXO into other public channels you necessarily associate those UTXOs with your node id and any descendent utxos. This is the point of UTXO probing too but with this you get the info for free by just passively observing the new channel gossip. I think this makes UTXO probing useless as long we can assume that public nodes that accept dual funding requests from random people on the internet (and therefore vulnerable to probing) are also likely to use their wallet funds to fund channels in the future. LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] PoDLEs revisited
Lloyd Fournier writes: > I think immediate broadcast of signaling TX is a bad idea even if it's done > over lightning since it leaks that the UTXO associated with the signaling > TX is creating a channel (even if the channel was meant to be private). > You could argue that the signaling TX need not be associated with a UTXO > but I find this awkward. > Lazily broadcast, signaling txs are a good way to protect against > sequential attacks but are weak against parallel attacks. Unfortunately I > think protection of the former means very little without the latter. Agreed. Let's PoDLE! > Let H0 and H1 be 32-byte output hash functions. > > 1. In any of the `tx_add_input` messages the initiator may attach a PoDLE > which contains the public key for an input as well as a P2 (the public key > projected onto a different generator). > 2. Upon receiving the PoDLE, the peer checks its validity and creates a > "claim" message claiming the UTXO which contains. > i) H0(P2) > ii) A MAC (e.g. Poly1305) produced with the H1(P2) as the key and > claimer_node_id as the message -- required so conflicting claim messages > can only be produced by someone who actually knows P2. > iii) The claimer_node_id and a BIP340 signature under it over the rest > of the message data -- required to stop spam: only accept and re-broadcast > these messages from nodes who have real channels. Note: we can avoid leaking claimer_node_id (Hey, look at me, someone's opening a channel with me now!). The purpose of claimer_node_id is to restrict spam (you need to have broadcasted a valid open channel to be recognized by the network as a valid node_id), but we can make this direct: require a utxo + the script needed to spend it, and any key in that script will serve in place of claimer_node_id (for v1 segwit, the output itself may serve as key). Since we're headed to an anchor (or Eltoo) world where nodes have to keep a few UTXOs around for emergencies anyway, this may have better privacy. At worst, they use a key from an existing, public channel UTXO, which is no worse than using their node_id. > Now I'd like to make the strongest possible argument against it in favor of > just doing nothing (for now) at the protocol level about this problem. > > Consider the following propositions: > 1. The public nodes that will offer dual funding and are susceptible to > this attack will be the kind that have a lot of churn i.e. they dual fund a > channel, when that closes they use the remaining funds to fund another > channel. > 2. Chainalysis already works very well at identifying the UTXOs these kinds > of nodes. If the change output of a funding or the closing output are > reused in another public channel it is easy to identify which node was > funding what with the techniques in [1,2]. Less true after taproot though? > 3. It is therefore rather redundant to do this type of active UTXO probing > since all you need to do is wait and be patient. Churning public nodes will > eventually use their UTXO to do a dual or single funding. Then by > cross-layer de-anonymization techniques you will be able to determine that > they owned that UTXO without ever interacting with the node. > 4. These techniques can even be applied to private channels at least while > they are identifiable on the blockchain (in [2] using chainalysis they can > identify one node involved in a private channel 79% of the time). > 5. There is of course some extra advantage in doing this attack but looking > at the effectiveness of techniques in [1,2] and my intuition about how > churning nodes are most susceptible to these techniques I *guess* it > wouldn't be much. If this is the case then chainalysis companies may not be > able to justify doing active attacks when passive attacks work almost as > well. > 6. It may be more effective to deal with UTXO probing outside of the > protocol. For example, a group of dual-funders could maintain a shared UTXO > blacklist and use chainalysis on it to not only ban single UTXOs but entire > clusters of outputs. i.e. do chainalysis on the chainalyzers! There are > some efforts to create open tools to do Chainalysis [3] that could be > leveraged against this attack. This might be much more effective than > PoDLEs as just spending the output somewhere else would not be enough to > use it again in the attack. > 7. The above PoDLE proposal actually creates a new extra bit of data that > can be used for chainalysis -- when you broadcast the claim message you are > saying you're going to make a dual funded channel sometime soon. So > Chainalysis can look in the next block for something that looks like a dual > funding and know you participated. This could be quite valuable for them > and I would hesitate to give it to them in the anticipation of them doing > an attack they may never actually do. > 8. If all of the above points are not enough to prevent this attack from > being widespread and the above PoDLE proposal is still the best idea I > g
Re: [Lightning-dev] PoDLEs revisited
On Wed, Jan 20, 2021 at 12:34 PM Rusty Russell wrote: > > > Yes, sorry. I assumed immediate broadcast + 60 second wait for > conflicts. It's this scheme I was trying to shoehorn into the mempool > (broadcast signalling tx, wait, try to RBF it with a real open). But > there are three problems with doing that: > > 1. Everyone knows what you're doing, as they see the signalling tx (and >it needs to commit to a challenge, such as using OP_RETURN, so you >can't simply reuse the same tx). > 2. Bitcoind doesn't tell you if it encounters a conflicting tx from a >peer, so we'd probably need to gossip this via lightning instead. > 3. If tx fees are low, the signalling tx might get mined. > I think immediate broadcast of signaling TX is a bad idea even if it's done over lightning since it leaks that the UTXO associated with the signaling TX is creating a channel (even if the channel was meant to be private). You could argue that the signaling TX need not be associated with a UTXO but I find this awkward. Lazily broadcast, signaling txs are a good way to protect against sequential attacks but are weak against parallel attacks. Unfortunately I think protection of the former means very little without the latter. > > > There are several (perhaps addressable) downsides to this scheme but it > at > > least has better protection against parallel attacks than the others. > > Since it is effective it would also break the "middleman" idea unless > Alice > > funds with two utxos (a different h2 for each party) or there is some way > > for all parties involved in the funding to distinguish gossiped h2s from > > their funding session from others. > > Yes, every initiator needs to provide an h2, and it has to be their own. > But you don't care (and can't know) that there's an h2 for another > input, too. If Alice wants to initialte an open with Carol while Bob is > initiating an opening with her, she's got to provide her own UTXO & > PoDLE. > > Another point: the idea was that the accepting node would sign the > gossip msg, and only known nodes (i.e. ones with a public channel) would > be allowed to do so. This gives easy anti-spam: if Alice starts > spamming a giant pile of h2s, we start randomly dropping them. That > doesn't degrade the protection much: a single UTXO reuse might slip > through, but a larger number would still be detected with P approaching > 1. > > Ok since it appears eagerly broadcasted PoDLEs are the only proposal that can protect against parallel attacks let's try and put the best version of it forward. Here's my shot. Let H0 and H1 be 32-byte output hash functions. 1. In any of the `tx_add_input` messages the initiator may attach a PoDLE which contains the public key for an input as well as a P2 (the public key projected onto a different generator). 2. Upon receiving the PoDLE, the peer checks its validity and creates a "claim" message claiming the UTXO which contains. i) H0(P2) ii) A MAC (e.g. Poly1305) produced with the H1(P2) as the key and claimer_node_id as the message -- required so conflicting claim messages can only be produced by someone who actually knows P2. iii) The claimer_node_id and a BIP340 signature under it over the rest of the message data -- required to stop spam: only accept and re-broadcast these messages from nodes who have real channels. The peer broadcasts this claim message if they haven't before received a valid claim message with H0(P2) and a valid MAC. 3. Any node receiving the claim message checks whether it has seen it already (same H0(P2) and MAC). If not, checks the signature against claimer_node_id and checks whether that node is valid (or perhaps blacklisted because it has spammed too many claim messages recently), stores (H0(P2), MAC, claimer_node_id) it and re-broadcasts the message to its peers. 4. The claiming node waits ~60 seconds to see if it receives a conflicting claim message where the H0(P2) is the same and the MAC is different and valid. If they don't receive that then they carry on to add their own utxos. I believe this does guarantee what we wanted: an attacker will only be able to do the attack once per UTXO. This is better than I expected to find at the beginning of entering into this subject! This certainly seems to be the strongest in the class of solutions. Now I'd like to make the strongest possible argument against it in favor of just doing nothing (for now) at the protocol level about this problem. Consider the following propositions: 1. The public nodes that will offer dual funding and are susceptible to this attack will be the kind that have a lot of churn i.e. they dual fund a channel, when that closes they use the remaining funds to fund another channel. 2. Chainalysis already works very well at identifying the UTXOs these kinds of nodes. If the change output of a funding or the closing output are reused in another public channel it is easy to identify which node was funding what with the techniques in [1,
Re: [Lightning-dev] PoDLEs revisited
Lloyd Fournier writes: > I think PoDLE might actually have an advantage in parallel attacks if the > scheme was changed a bit. A weakness of the lightning proposal as compared > to the joinmarket idea is that the `h2` point is not broadcast immediately > -- rather you wait for failure and then broadcast it. Instead, a peer > should broadcast h2 as soon as they have agreed to create a transaction > with the initiator. Then if at any time during the tx creation protocol > they receive the same h2 from someone else, they cancel and don't reveal > their UTXOs (let's say they wait ~10s after broadcasting before revealing > any utxos). Note that here you don't have to randomly select the time you > wait. Yes, sorry. I assumed immediate broadcast + 60 second wait for conflicts. It's this scheme I was trying to shoehorn into the mempool (broadcast signalling tx, wait, try to RBF it with a real open). But there are three problems with doing that: 1. Everyone knows what you're doing, as they see the signalling tx (and it needs to commit to a challenge, such as using OP_RETURN, so you can't simply reuse the same tx). 2. Bitcoind doesn't tell you if it encounters a conflicting tx from a peer, so we'd probably need to gossip this via lightning instead. 3. If tx fees are low, the signalling tx might get mined. > There are several (perhaps addressable) downsides to this scheme but it at > least has better protection against parallel attacks than the others. > Since it is effective it would also break the "middleman" idea unless Alice > funds with two utxos (a different h2 for each party) or there is some way > for all parties involved in the funding to distinguish gossiped h2s from > their funding session from others. Yes, every initiator needs to provide an h2, and it has to be their own. But you don't care (and can't know) that there's an h2 for another input, too. If Alice wants to initialte an open with Carol while Bob is initiating an opening with her, she's got to provide her own UTXO & PoDLE. Another point: the idea was that the accepting node would sign the gossip msg, and only known nodes (i.e. ones with a public channel) would be allowed to do so. This gives easy anti-spam: if Alice starts spamming a giant pile of h2s, we start randomly dropping them. That doesn't degrade the protection much: a single UTXO reuse might slip through, but a larger number would still be detected with P approaching 1. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] PoDLEs revisited
On Wed, Jan 13, 2021 at 11:54 AM Rusty Russell wrote: > Lloyd Fournier writes: > > Rusty, Zman, > > > > A concern I have with only doing one signaling transaction out of the > whole > > group of inputs is that it means you don't prove ownership of the other > > inputs. > > But that's by design. You can contact two peers and middleman between > them to produce a single tx. > Ah. I missed this motivation. So you actually want to have sessions where you use the same signaling transaction in all of them. That's a cool idea. > > The practical problem with a signalling tx is that it's hard to tell if > it's conflicting. Mallory uses a single UTXO to probe for everyone's > UTXO at once. Poor Bob wants to both wait 60 seconds to see if a > conflicting tx ends up in his mempool, *and* broadcast it ASAP to signal > to others. He wants to do both of these *before* revealing his own > UTXOs. > > I think this is a problem with all three schemes I mentioned. You will always have to wait for things to be gossiped in some way to catch attempts at parallel sessions. Of course there could be faster mediums than the mempool but it does seem a convenient one to use. Note that you should not wait a predictable amount of time but rather a randomly sampled amount from e.g. 0-60 seconds (or longer). If everyone is waiting the same predictable amount of time it does nothing to protect you. But the "middleman" idea you mentioned above makes this all the more complicated: If you are meant to have parallel sessions then this is a problem for an honest Alice who initiates a funding with Bob and Carol. Bob decides to wait 24s and Carol decides to wait 55s to check the mempool for the signaling before revealing their utxos. After Bob wakes up from his 24s he will add his own utxos and demand that Alice complete the transaction by signing it. But since Alice is trying to also add Carol's UTXOs to the transaction she will have to wait until Carol becomes responsive again. To Bob this will look like Alice has become unresponsive through no fault of her own and Bob will broadcast the signaling tx. In other words, if parallel sessions are legal then you shouldn't try and catch parallel sessions. But if parallel sessions are legal there will always be an effective dual funding UTXO discovery attack by using one UTXO to hit many targets. I think this is true for all three schemes I mentioned. It seems the really difficult question is: is it even worth trying to stop sequential attacks if parallel attacks are unstoppable? Not sure how to square this, but I do prefer this approach over PoDLE. > I think PoDLE might actually have an advantage in parallel attacks if the scheme was changed a bit. A weakness of the lightning proposal as compared to the joinmarket idea is that the `h2` point is not broadcast immediately -- rather you wait for failure and then broadcast it. Instead, a peer should broadcast h2 as soon as they have agreed to create a transaction with the initiator. Then if at any time during the tx creation protocol they receive the same h2 from someone else, they cancel and don't reveal their UTXOs (let's say they wait ~10s after broadcasting before revealing any utxos). Note that here you don't have to randomly select the time you wait. There are several (perhaps addressable) downsides to this scheme but it at least has better protection against parallel attacks than the others. Since it is effective it would also break the "middleman" idea unless Alice funds with two utxos (a different h2 for each party) or there is some way for all parties involved in the funding to distinguish gossiped h2s from their funding session from others. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] PoDLEs revisited
Lloyd Fournier writes: > Rusty, Zman, > > A concern I have with only doing one signaling transaction out of the whole > group of inputs is that it means you don't prove ownership of the other > inputs. But that's by design. You can contact two peers and middleman between them to produce a single tx. The practical problem with a signalling tx is that it's hard to tell if it's conflicting. Mallory uses a single UTXO to probe for everyone's UTXO at once. Poor Bob wants to both wait 60 seconds to see if a conflicting tx ends up in his mempool, *and* broadcast it ASAP to signal to others. He wants to do both of these *before* revealing his own UTXOs. Not sure how to square this, but I do prefer this approach over PoDLE. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] PoDLEs revisited
Rusty, Zman, A concern I have with only doing one signaling transaction out of the whole group of inputs is that it means you don't prove ownership of the other inputs. I am not exactly sure what you could do by adding inputs from the chain you don't own but it does feel a bit risky. Perhaps it would allow you to add whale output from the chain to trick the peer's algorithm for deciding how much they want to add to the funding. Perhaps regulators of the future might check whether the LN node is following their directive to ban certain inputs on a blacklist -- If you carry on after the funding_add_input from a blacklisted input you must not be running our gov approved node! If that is not a concern, then I agree a single 1-input-1-output signaling transaction should be fine, otherwise requiring 1-input-1-output signaling tx for each input the opener adds may be prudent (as Z suggested). > [2] Which Lisa promises she'll publish RSN, so we can add your derived points proposal to it. Looking forward to seeing this :) Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] PoDLEs revisited
Lloyd Fournier writes: > This achieves all properties except for (4 - distinguishable on-chain) > which is why it was dismissed. It also seems to require 2 txs per channel open? (Interestingly I missed that post previously, thanks for the pointer!) > I think it is possible to extend the idea to achieve (4) and therefore > obtain all desired properties. > Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups > in case of abort. Here's how it could work in my mind: > > 1. Initiator requests dual-funding and provides a TX_temp spending their > input set to a main output and a change output (does not sign it yet). They > also provide a sighash SIGNLE|ANYONECANPAY signature on the main output > spending into TX_backup-fund and a signature on the first commitment > transaction spending from TX_backup-fund (exactly as in [6]). > 2. Peer responds with commitment TX signature for TX_backup-fund. > 3. Initiator responds with the signatures for TX_temp. > *Peer now has a fully functional transaction chain with which to open the > channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*. > 4. Peer (if possible) checks there are no existing transactions in the > chain or mempool spending from the taker's inputs. If not it responds with > its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund. > 5. Initiator responds with commitment TX signature and TX_fund input > signatures. > 6. Peer broadcasts TX_fund. > *If at any point after step 3 Initiator does not respond for ~2 seconds > they broadcast TX_temp and TX_backup-funding* 2 seconds is not sufficient; as an Australian (or Tor user) you should know this :) But otherwise, it's kinda nice (bar breaking the interactive construction). > We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain > in case of abort (i.e. TX_backup-funding makes it on-chain). > It appears to be pretty close to the ideal solution in terms of privacy and > security. > If the malicious initiator learns an output they will always have to spend > one of their inputs otherwise they will quickly get hit by the TX_temp + > TX_backup-funding. > Note that it is possible the node is just slow in which case even if step > TX_backup-funding makes it in both parties should just carry on with the > channel. > > The downsides are that it involves six rounds of communication and cannot > use the "interactive tx building" protocol developed for the original > proposal > > # Signaling Transactions > > Finally I present a simple but unintuitive protocol that achieves roughly > the same properties as the PoDLE protocol but without lightning gossip > messages. > > Whenever the initiator adds an input in the interactive tx building they > provide signatures on a "signaling" transaction spending that input (and > any inputs they have added so far). > The signaling transactions will typically spend the funds back to the > initiator's wallet. > Before revealing any of their inputs, the peer checks that none of the > inputs added by the initiator are in their mempool/chain. > If the initiator aborts the protocol after learning one of the peer's > inputs the peer broadcasts one of the signaling transactions. > > Like the PoDLE proposal this doesn't achieve (3) since a malicious peer > could broadcast the signaling transaction making the honest initiator pay a > transaction fee before using the input in another session. > To mitigate this a bit, the transactions could be RBF and have a 1 > sat-per-byte feerate to give the initiator a decent amount of time to use > their input productively before the tx confirms (and paying a low fee if it > ever does confirm). > > The advantages of signaling transactions over PoDLE is that it doesn't > involve any wonky crypto or new gossip messages. > The advantage of the PoDLE proposal over this is that a malicious peer can > only blacklist the UTXO (not necessarily force you to spend it). We only need a single UTXO for this, which is even better. So the initiator sends a "good faith" signed tx, which spends one of its UTXOs, to the accepter. 1sat-per-byte is probably a too low, but the accepter can provide a feerate for it[1]. Opener aborts if that "good-faith" feerate is too high. It's implied that this is the first added input, too. If the accepter screws the opener by broadcasting it, the opener can still open a channel with someone else before it's confirmed: they just can't use *that* utxo if they want another node to DF. Or simply take the loss, since the feerate is presumably minimal, and use CPFP. Cheers, Rusty. [1] The latest c-lightning implementation of the spec[2] already has the accepter indicating min, max and preferred feerates (and then the opener selects within that range). This would simply add another feerate field, suggest implementing as ceiling(min / 2, 1). [2] Which Lisa promises she'll publish RSN, so we can add your derived points proposal to it.
Re: [Lightning-dev] PoDLEs revisited
Good morning LL, and happy new year as well, > # Signaling Transactions > > Finally I present a simple but unintuitive protocol that achieves roughly the > same properties as the PoDLE protocol but without lightning gossip messages. > > Whenever the initiator adds an input in the interactive tx building they > provide signatures on a "signaling" transaction spending that input (and any > inputs they have added so far). > The signaling transactions will typically spend the funds back to the > initiator's wallet. > Before revealing any of their inputs, the peer checks that none of the inputs > added by the initiator are in their mempool/chain. > If the initiator aborts the protocol after learning one of the peer's inputs > the peer broadcasts one of the signaling transactions. I would suggest rather that each added input should add a one-input one-output signaling transaction, instead. Consider the case of a malicious initiator who has two coins A and B. * Mallory sends A with a signalling transaction spending A. * Mallory sends B with a signalling transaction spending A and B. * Victor the victim initiatee node sends its coins. * Mallory spends A to itself, using a different transaction, with a feerate that is slightly higher than the feerate of the signaling transaction spending A and B. Mallory only needs to spend A, and there is no way for Victor to impose a cost on the use of B --- the signaling transactions available to Victor spend A and cannot replace the non-signaling transaction that Mallory created. So I think it is better if there is one signaling transaction per input provided by the initiator. Alternately, we can consider that Mallory will rationally want to reduce its exposure to cost, and would prefer to just provide a single input on each initiation. If Mallory is in possession of multiple coins, it is in the best interest of Mallory to use each coin on a different Victor to spread out its risk *and* retain its own privacy, anyway, and not give two or more inputs to each Victor. Thus, we only really need one signalling transaction, that for the first input provided by the initiator, and the single signalling transaction is sufficient to impose costs on Mallory. > > Like the PoDLE proposal this doesn't achieve (3) since a malicious peer could > broadcast the signaling transaction making the honest initiator pay a > transaction fee before using the input in another session. > To mitigate this a bit, the transactions could be RBF and have a 1 > sat-per-byte feerate to give the initiator a decent amount of time to use > their input productively before the tx confirms (and paying a low fee if it > ever does confirm). > > The advantages of signaling transactions over PoDLE is that it doesn't > involve any wonky crypto or new gossip messages. > The advantage of the PoDLE proposal over this is that a malicious peer can > only blacklist the UTXO (not necessarily force you to spend it). > > # Summary > > The preference of protocol depends on how you weigh the importance of a > malicious non-initiating peer griefing the initiator. > To protect fully, the extended version of Darosior's protocol does not allow > griefing. > There is always a lot to be said for ruling out a class of attack even if it > costs you a few rounds of communication. > > Is griefing a real concern though? Layer-2 is full of opportunities to grief > your counterparty and the ones presented here are hardly the worst. > If you're opening channels with someone who wants to grief you, you are > already in trouble. > PoDLEs have very weak griefing in the form of unfairly adding your UTXO to > the blacklist but comes at the cost of complexity and a few difficult to > answer questions. > I think the simplicity of signaling transactions may be worth the extra > griefing capabilities it offers a malicious peer given they are hardly as bad > as the griefing capabilities they will have if you open a channel to them! Indeed. With the network already "booted up", so to speak, in general, a node will prefer to initiate channels with existing nodes that have: * High uptime. * Good connectivity and capacity. * Long-lived channels. A node which acts as a passive malicious peer in this protocol *could* have gotten another channel to justify its high uptime and locked funds, and potentially earn more funds in the future, rather than pissing off the incoming initiator by this form of griefing. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
