[Lightning-dev] c-lightning discord community
FYI c-lightning now has a discord server for general questions, dev-chats, and community support. You can join it here: https://discord.gg/WW56GGHavu We're also still on Telegram at https://t.me/lightningd and IRC at #c-lightning on the libera.chat node. ~nifty ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...
Hi Matt, I like this proposal, it's a net improvement compared to hodling HTLCs at the recipient's LSP. With onion messages, we do have all the tools we need to build this. I don't think we can do much better than that anyway if we want to keep payments fully non-custodial. This will be combined with notifications to try to get the recipient to go online asap. One thing to note is that the senders also need to come online while the payment isn't settled, otherwise there is a risk they'll lose their channels. If the sender's LSP receives the preimage but the sender does not come online, the sender's LSP will have to force-close to claim the HTLC on-chain when it gets close to the timeout. Definitely not a show-stopper, just an implementation detail to keep in mind. Bastien Le jeu. 14 oct. 2021 à 02:20, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > Good morning Matt, > > > On 10/13/21 02:58, ZmnSCPxj wrote: > > > > > Good morning Matt, > > > > > > > The Obvious (tm) solution here is PTLCs - just have the sender > always add some random nonce * G to > > > > the PTLC they're paying and send the recipient a random nonce > in the onion. I'd generally suggest we > > > > just go ahead and do this for every PTLC payment, cause why > not? Now the sender and the lnurl > > > > endpoint have to collude to steal the funds, but, like, the > sender could always just give the lnurl > > > > endpoint the money. I'd love suggestions for fixing this short > of PTLCs, but its not immediately > > > > obvious to me that this is possible. > > > > > > > > > > Use two hashes in an HTLC instead of one, where the second hash is > from a preimage the sender generates, and which the sender sends (encrypted > via onion) to the receiver. > > > You might want to do this anyway in HTLC-land, consider that we have a > `payment_secret` in invoices, the second hash could replace that, and > provide similar protection to what `payment_secret` provides (i.e. > resistance against forwarding nodes probing; the information in both cases > is private to the ultimate sender and ultimate reeceiver). > > > > Yes, you could create a construction which does this, sure, but I'm not > sure how you'd do this > > without informing every hop along the path that this is going on, and > adapting each hop to handle > > this as well. I suppose I should have been more clear with the > requirements, or can you clarify > > somewhat what your proposed construction is? > > Just that: two hashes instead of one. > Make *every* HTLC on LN use two hashes, even for current "online RPi user > pays online RPi user" --- just use the `payment_secret` for the preimage of > the second hash, the sender needs to send it anyway. > > > > > If you're gonna adapt every node in the path, you might as well just use > PTLC. > > Correct, we should just do PTLCs now. > (Basically, my proposal was just a strawman to say "we should just do > PTLCs now") > > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
Good morning Joost, > There could be some corners where the incentives may not work out 100%, but I > doubt that any routing node would bother exploiting this. Especially because > there could always be that reputation scheme at the sender side which may > cost the routing node a lot more in lost routing fees than the marginal gain > from the upfront payment. > > Another option is that nodes that don't care to be secretive about their > channel balances could include the actual balance in a probe failed message. > Related: https://github.com/lightningnetwork/lightning-rfc/pull/695 > > Overall it seems that htlc-less probes are an improvement to what we > currently have. Immediate advantages include a reduction of the load on nodes > by cutting out the channel update machinery, better ux (faster probes) and no > locked up liquidity. On the longer term it opens up the option to charge for > failed payments so that we finally have an answer to channel jamming. One can argue that if you are hoping that forwarding nodes will not exploit this, you can also hope that forwarding nodes will not perform channel-jamming attacks. As I noted before, channel jamming attacks will never be performed by payers or payees --- they have an incentive to complete the transaction and earn gains from trade. Channel jamming attacks are performed by large forwarding nodes on their smaller competitors, since having 100 capacity on large versus 10 capacity on the smaller competitor is worse than having 89 capacity on the large versus 0 capacity on the smaller competitor. On the other hand, perhaps it is at this point that we should start computing the exact incentives, hmm. -- A thing to note is that any node along a path can disrupt an onion response by the simple expedient of XORing it with random stuff, or even just a non-0 constant. This may allow for an additional attack vector. Suppose I am a forwarding node and I receive a probe request, and it turns out the next hop lacks capacity right now. I could incite the next hop to lie by forwarding the probe request to the next hop despite the lack of capacity. If the next hop responds immediately, I can then corrupt the return onion. Presumably if the next hop responded immediately it was reporting my lie to the sender. By corrupting the return onion the ultimate sender is unable to determine *which* node along the route failed, and I can hope that the reputation penalty to my competitor forwarding nodes along the path compensates for the reputation hit I personally suffer. If the next hop takes some time before responding, then possibly it colluded with me to lie about the capacity on our channel (i.e. it actually went ahead and forwarded to the next hop despite knowing I lied). Then I could faithfully onion-encrypt the response and send it back to the ultimate sender. To mitigate against the above attack: * If a forwarding node gets a probe request for an amount that the asker is *currently* unable to give anyway: * The forwarding node should still forward the probe request. * On response, however, it replaces the response with its own report that the previous hop was a dirty liar. * Note that the asker is the one who has full control over their funds in the channel, so the asker cannot later claim "but the network latency mixed up our messages!" --- the asker knows when it does `update_add_htlc` to reduce its capacity, so it should know it has the capacity or not. Now, if we are going to add a message "the previous hop was a dirty liar" then we should ask if a forwarding node would want to make a false accusation. * Suppose the previous hop has sufficient capacity and asked us if we have our own capacity. * Does the current hop have any incentive to falsely accuse the previous hop? * No: if it did, then the sender would not try their channel again in the close future, thus leading to lower fee earnings. > ZmnSCPxj, as first person to propose the idea (I think?), would you be > interested in opening a draft PR on the spec repository that outlines the new > message(s) that we'd need and continue detailing from there? It might end up not happening given the stuff I juggle randomly, so feel free to start it. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
There could be some corners where the incentives may not work out 100%, but I doubt that any routing node would bother exploiting this. Especially because there could always be that reputation scheme at the sender side which may cost the routing node a lot more in lost routing fees than the marginal gain from the upfront payment. Another option is that nodes that don't care to be secretive about their channel balances could include the actual balance in a probe failed message. Related: https://github.com/lightningnetwork/lightning-rfc/pull/695 Overall it seems that htlc-less probes are an improvement to what we currently have. Immediate advantages include a reduction of the load on nodes by cutting out the channel update machinery, better ux (faster probes) and no locked up liquidity. On the longer term it opens up the option to charge for failed payments so that we finally have an answer to channel jamming. ZmnSCPxj, as first person to propose the idea (I think?), would you be interested in opening a draft PR on the spec repository that outlines the new message(s) that we'd need and continue detailing from there? Joost On Sat, Oct 16, 2021 at 12:51 AM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Owen, > > > C now notes that B is lying, but is faced with the dilemma: > > > > "I could either say 'no' because I can plainly see that B is lying, or > > I could say 'yes' and get some free sats from the failed payment (or > > via the hope of a successful payment from a capacity increase in the > > intervening milliseconds)." > > Note that if B cannot forward an HTLC to C later, then C cannot have a > failed payment and thus cannot earn any money from the upfront payment > scheme; thus, at least that part of the incentive is impossible. > > On the other hand, there is still a positive incentive for continuing the > lie --- later, maybe the capacity becomes OK and C could earn both the > upfront fee and the success fee. > > > So C decides it's in his interest to keep the lie going. D, the payee, > > can't tell that it's a lie when it reaches her. > > > > If C did want to tattle, it's important that he be able to do so in a > > way that blames B instead of himself, otherwise payers will assume > > (incorrectly, and to C's detriment) that the liquidity deficit is with C > > rather than B. > > That is certainly quite possible to do. > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning over taproot with PTLCs
On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote: > Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of > taproot and implement PTLCs. I think the conclusion from the discussions at the in-person LN summit was to split these features up an implement them gradually. I think that would look like: 1) taproot funding/anchor output benefits: * LN utxos just look normal, so better privacy * mutual closes also look normal, and only need one sig and no script, better privacy and lower fees * doesn't require updating any HTLC scripts complexities: * requires implementing musig/musig2/similar for mutual closes and signing commitment txs * affects gossip, which wants to link channels with utxos so needs to understand the new utxo format * affects splicing -- maybe it's literally an update to the splicing spec, and takes effect only when you open new channels or splice existing ones? 2) update commitment outputs to taproot benefits: * slightly cheaper unilateral closes, maybe more private? complexities: * just need to support taproot script path spends 3) PTLC outputs benefits: * has a different "hash" at every hop, arguably better privacy * can easily do cool things with points/secrets that would require zkp's to do with hashes/secrets * no need to remember PTLCs indefinitely in case of old complexities: * needs a routing feature bit * not usable unless lots of the network upgrades to support PTLCs * requires implementing adaptor signatures 4) symmetric commitment tx (revocation via signature info) benefits: * reduces complexity of layered txs? * reduces gamesmanship of who posts the commitment tx? * enables low-latency/offline payments? complexities: * requires careful nonce management? 5) low-latency payments? benefits: * for payments that have no problems, halves the time to complete * the latency introduced by synchronous commitment updates doesn't matter for successful payments, so peer protocol can be simplified complexities: * ? 6) offline receipt? 7) eltoo channels? 8) eltoo factories? Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
