rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 Original date posted:2021-10-19 📝 Original message: 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 at 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 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/20211019/dd316d31/attachment.html>