{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-05-06\n🗒️ Summary of this message: The Lightning Network community is exploring data gathering and local reputation tracking to mitigate channel jamming, starting with a binary endorsement field. They aim to experiment with different algorithms for tracking local reputation and gather real-world data for future simulation work.\n📝 Original message:\nHi *,\n\n\u003e Our suggestion is to start simple with a binary endorsement field. As\n\u003e we learn more, we will be better equipped to understand whether a\n\u003e more expressive value is required.\n\nI think the HTLC endorsement scheme as proposed is still suffering from a\nvulnerability as local reputation can be built up during periods of low\nrouting fees, endorsement gained and then abused during periods of high\nrouting fees. Therefore, it sounds to me this scheme should aim for some\nreputational transitivity between incoming traffic and outgoing traffic.\nNamely, the acquisition cost of the local reputation should be equal to the\nmax timevalue damage that one can inflict on a routing node channel\naccessible from its local counterparty granting this high-level of\nreputation.\n\nI don't know if this can be fixed by ensuring permanent link-level \"gossip\"\nwhere counterparties along a payment path expose their reputation\nheuristics to guarantee this transitivity, or it's a fundamental issue with\na point-to-point approach like HTLC endorsement.\n\nOpened an issue on the repository to converge on a threat model:\nhttps://github.com/ClaraShk/LNJamming/pull/13\n\nI still think building data gathering infrastructure for Lightning is\nvaluable as ultimately any jamming mitigation will have to adapt its\nupfront fees or reputation acquisition cost in function of HTLC traffic and\nmarket forces.\n\nLooking forward to giving an update on Staking Credentials [0], an\nend-to-end approach to mitigate channel jamming.\n\nBest,\nAntoine\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html\n\nLe dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen \u003ckirkcohenc at gmail.com\u003e a\nécrit :\n\n\u003e Hi list,\n\u003e\n\u003e Some updates on channel jamming!\n\u003e\n\u003e # Next Call\n\u003e - Monday 01 May @ 15:00 UTC\n\u003e - https://meet.jit.si/UnjammingLN\n\u003e - Agenda: https://github.com/ClaraShk/LNJamming/issues/12\n\u003e\n\u003e # Data Gathering\n\u003e During these weekly calls, we've come to agreement that we would like\n\u003e to gather data about the use of HTLC endorsement and local reputation\n\u003e tracking for jamming mitigation. A reminder of the full scheme is\n\u003e included at the end of this email, and covered more verbosely in [1].\n\u003e\n\u003e We have a few goals in mind:\n\u003e - Observe the effect of endorsement in the steady state with\n\u003e   logging-only implementation.\n\u003e - Gather real-world data for use in future simulation work.\n\u003e - Experiment with different algorithms for tracking local reputation.\n\u003e\n\u003e The minimal changes required to add HTLC endorsement are outlined in [2].\n\u003e Our suggestion is to start simple with a binary endorsement field. As\n\u003e we learn more, we will be better equipped to understand whether a\n\u003e more expressive value is required.\n\u003e\n\u003e With this infrastructure in place, we can start to experiment with\n\u003e various local reputation schemes and data gathering, possibly even\n\u003e externally to LN implementations in projects like circuitbreaker [3].\n\u003e We'd be interested to hear whether there's any appetite to deploy using\n\u003e an experimental TLV value?\n\u003e\n\u003e # Reputation Scheme\n\u003e - Each node locally tracks the reputation of its direct neighbors.\n\u003e - Each node allocates, per its risk tolerance:\n\u003e   - A number of slots reserved for endorsed HTLCs from high reputation\n\u003e     peers.\n\u003e   - A portion of liquidity reserved for endorsed HTLCs from high\n\u003e     reputation peers.\n\u003e - Forwarding of HTLCs:\n\u003e   - If a HTLC is endorsed by a high reputation peer, it is forwarded\n\u003e     as usual with endorsed = 1.\n\u003e   - Otherwise, it is forwarded with endorsed = 0 if there are slots and\n\u003e     liquidity available for unknown HTLCs.\n\u003e\n\u003e Endorsement and reputation are proposed as the first step in a two part\n\u003e scheme for mitigating channel jamming:\n\u003e - Reputation for slow jams which are easily detected as misbehavior.\n\u003e - Unconditional fees for quick jams that are difficult to detect, as\n\u003e   they can always fall under a target threshold.\n\u003e\n\u003e Looking forward to discussing further in the upcoming call!\n\u003e\n\u003e Best,\n\u003e Carla and Clara\n\u003e\n\u003e [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343\n\u003e [2] https://github.com/lightning/bolts/pull/1071\n\u003e [3] https://github.com/lightningequipment/circuitbreaker\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/20230506/40daccce/attachment.html\u003e"}