{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-10-19\n📝 Original message:\nThere could be some corners where the incentives may not work out 100%, but\nI doubt that any routing node would bother exploiting this. Especially\nbecause there could always be that reputation scheme at the sender side\nwhich may cost the routing node a lot more in lost routing fees than the\nmarginal gain from the upfront payment.\n\nAnother option is that nodes that don't care to be secretive about their\nchannel balances could include the actual balance in a probe failed\nmessage. Related: https://github.com/lightningnetwork/lightning-rfc/pull/695\n\nOverall it seems that htlc-less probes are an improvement to what we\ncurrently have. Immediate advantages include a reduction of the load on\nnodes by cutting out the channel update machinery, better ux (faster\nprobes) and no locked up liquidity. On the longer term it opens up the\noption to charge for failed payments so that we finally have an answer to\nchannel jamming.\n\nZmnSCPxj, as first person to propose the idea (I think?), would you be\ninterested in opening a draft PR on the spec repository that outlines the\nnew message(s) that we'd need and continue detailing from there?\n\nJoost\n\nOn Sat, Oct 16, 2021 at 12:51 AM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Owen,\n\u003e\n\u003e \u003e C now notes that B is lying, but is faced with the dilemma:\n\u003e \u003e\n\u003e \u003e \"I could either say 'no' because I can plainly see that B is lying, or\n\u003e \u003e I could say 'yes' and get some free sats from the failed payment (or\n\u003e \u003e via the hope of a successful payment from a capacity increase in the\n\u003e \u003e intervening milliseconds).\"\n\u003e\n\u003e Note that if B cannot forward an HTLC to C later, then C cannot have a\n\u003e failed payment and thus cannot earn any money from the upfront payment\n\u003e scheme; thus, at least that part of the incentive is impossible.\n\u003e\n\u003e On the other hand, there is still a positive incentive for continuing the\n\u003e lie --- later, maybe the capacity becomes OK and C could earn both the\n\u003e upfront fee and the success fee.\n\u003e\n\u003e \u003e So C decides it's in his interest to keep the lie going. D, the payee,\n\u003e \u003e can't tell that it's a lie when it reaches her.\n\u003e \u003e\n\u003e \u003e If C did want to tattle, it's important that he be able to do so in a\n\u003e \u003e way that blames B instead of himself, otherwise payers will assume\n\u003e \u003e (incorrectly, and to C's detriment) that the liquidity deficit is with C\n\u003e \u003e rather than B.\n\u003e\n\u003e That is certainly quite possible to do.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211019/dd316d31/attachment.html\u003e"}