{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-10-19\n📝 Original message:\nGood morning Joost,\n\n\u003e 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.\n\u003e\n\u003e 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\n\u003e\n\u003e 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.\n\nOne 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.\nAs 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.\nChannel 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.\n\nOn the other hand, perhaps it is at this point that we should start computing the exact incentives, hmm.\n\n--\n\nA 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.\nThis may allow for an additional attack vector.\n\nSuppose I am a forwarding node and I receive a probe request, and it turns out the next hop lacks capacity right now.\nI could incite the next hop to lie by forwarding the probe request to the next hop despite the lack of capacity.\n\nIf the next hop responds immediately, I can then corrupt the return onion.\nPresumably if the next hop responded immediately it was reporting my lie to the sender.\nBy 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.\n\nIf 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).\nThen I could faithfully onion-encrypt the response and send it back to the ultimate sender.\n\n\nTo mitigate against the above attack:\n\n* If a forwarding node gets a probe request for an amount that the asker is *currently* unable to give anyway:\n  * The forwarding node should still forward the probe request.\n  * On response, however, it replaces the response with its own report that the previous hop was a dirty liar.\n  * 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.\n\n\nNow, 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.\n\n* Suppose the previous hop has sufficient capacity and asked us if we have our own capacity.\n* Does the current hop have any incentive to falsely accuse the previous hop?\n  * No: if it did, then the sender would not try their channel again in the close future, thus leading to lower fee earnings.\n\n\n\u003e 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?\n\nIt might end up not happening given the stuff I juggle randomly, so feel free to start it.\n\nRegards,\nZmnSCPxj"}