{"type":"rich","version":"1.0","author_name":"npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpam","author_url":"https://nostr.ae/npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpam","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-05-10\n🗒️ Summary of this message: Reputation data can assist in making probabilistic judgments about future behavior, but it cannot guarantee security. It is not a protocol or P2P gossiping issue, and there may be competing reputation data providers and services.\n📝 Original message:\n\u003eFrom my perspective it really comes down to whether you want security *guarantees* or data to assist you in making probabilistic judgments about future behavior. Reputation data or reputation systems will never give you guarantees for the reasons Christian explains. But reputation data is better than nothing and depending on the quality and granularity of the data could be considerably better than nothing. In the most basic case of deciding on a potential channel counterparty I would much rather choose a counterparty who has demonstrated competence and reliability over a number of years than a channel counterparty who has just joined the network and who I know nothing about. Similarly a Lightning node that hasn't carried a jamming attack for multiple years despite having the opportunity to is a much better bet than a Lightning node of which I know nothing.\n\nNow where it sits on the software stack assuming a user opts into such a reputation \"service\" (plugin maybe or more likely an API) is I think what in essence this discussion is about. As I've already stated previously and which I agree with Christian on is that it isn't/shouldn't be a protocol or a P2P gossiping issue. In the same way as we have multiple Lightning explorers (1ML, Amboss etc) that aren't part of the Lightning protocol or part of the \"core\" of a Lightning node you can expect there would be competing reputation data providers and services. Also many users for privacy and/or other reasons won't be interested in using or participating in (to the extent they can opt out if the data is public) a reputation service.\n\nSo yeah I think I'm somewhere in between Christian's and Antoine's perspectives here. I do think there are interesting projects, services or even businesses in this area of reputation but it isn't a protocol/P2P gossiping issue or a \"core\" of a Lightning node issue.\n\nThanks\nMichael\n\n[0]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003766.html\n\n--\nMichael Folkson\nEmail: michaelfolkson at protonmail.com\nGPG: A2CF5D71603C92010659818D2A75D601B23FEE0F\nLearn about Bitcoin: https://www.youtube.com/@portofbitcoin\n\n\n------- Original Message -------\nOn Wednesday, May 10th, 2023 at 12:57, Christian Decker \u003cdecker.christian at gmail.com\u003e wrote:\n\n\n\u003e Hi Antoine,\n\u003e \n\u003e this is an intrinsic issue with reputation systems, and the main\n\u003e reason I'm sceptical w.r.t. their usefulness in lightning.\n\u003e Fundamentally any reputation system bases their expectations for the\n\u003e future on experiences they made in the past, and they are thus always\n\u003e susceptible to sudden behavioral changes (going rogue from a prior\n\u003e clean record) and whitewashing attacks (switching identity, abusing\n\u003e any builtin bootstrapping method for new users to gain a good or\n\u003e neutral reputation before turning rogue repeatedly).\n\u003e \n\u003e This gets compounded as soon as we start gossiping about reputations,\n\u003e since now our decisions are no longer based just on information we can\n\u003e witness ourselves, or at least verify its correctness, and as such an\n\u003e attacker can most likely \"earn\" a positive reputation in some other\n\u003e part of the world, and then turn around and attack the nodes that\n\u003e trusted the reputation shared from those other parts.\n\u003e \n\u003e I'd be very interested in how many repeat interactions nodes get from\n\u003e individual senders, since that also tells us how much use we can get\n\u003e out of local-only reputation based systems, and I wouldn't be\n\u003e surprised if, for large routing nodes, we have sufficient data for\n\u003e them to make an informed decision, while the edges may be more\n\u003e vulnerable, but they'd also be used by way fewer senders, and the\n\u003e impact of an attack would also be proportionally smaller.\n\u003e \n\u003e Cheers,\n\u003e Christian\n\u003e \n\u003e On Mon, May 8, 2023 at 10:26 PM Antoine Riard antoine.riard at gmail.com wrote:\n\u003e \n\u003e \u003e Hi *,\n\u003e \u003e \n\u003e \u003e \u003e Our suggestion is to start simple with a binary endorsement field. As\n\u003e \u003e \u003e we learn more, we will be better equipped to understand whether a\n\u003e \u003e \u003e more expressive value is required.\n\u003e \u003e \n\u003e \u003e I think the HTLC endorsement scheme as proposed is still suffering from a vulnerability as local reputation can be built up during periods of low routing fees, endorsement gained and then abused during periods of high routing fees. Therefore, it sounds to me this scheme should aim for some reputational transitivity between incoming traffic and outgoing traffic. Namely, the acquisition cost of the local reputation should be equal to the max timevalue damage that one can inflict on a routing node channel accessible from its local counterparty granting this high-level of reputation.\n\u003e \u003e \n\u003e \u003e I don't know if this can be fixed by ensuring permanent link-level \"gossip\" where counterparties along a payment path expose their reputation heuristics to guarantee this transitivity, or it's a fundamental issue with a point-to-point approach like HTLC endorsement.\n\u003e \u003e \n\u003e \u003e Opened an issue on the repository to converge on a threat model:\n\u003e \u003e https://github.com/ClaraShk/LNJamming/pull/13\n\u003e \u003e \n\u003e \u003e I still think building data gathering infrastructure for Lightning is valuable as ultimately any jamming mitigation will have to adapt its upfront fees or reputation acquisition cost in function of HTLC traffic and market forces.\n\u003e \u003e \n\u003e \u003e Looking forward to giving an update on Staking Credentials [0], an end-to-end approach to mitigate channel jamming.\n\u003e \u003e \n\u003e \u003e Best,\n\u003e \u003e Antoine\n\u003e \u003e \n\u003e \u003e [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html\n\u003e \u003e \n\u003e \u003e Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen kirkcohenc at gmail.com a écrit :\n\u003e \u003e \n\u003e \u003e \u003e Hi list,\n\u003e \u003e \u003e \n\u003e \u003e \u003e Some updates on channel jamming!\n\u003e \u003e \u003e \n\u003e \u003e \u003e # Next Call\n\u003e \u003e \u003e - Monday 01 May @ 15:00 UTC\n\u003e \u003e \u003e - https://meet.jit.si/UnjammingLN\n\u003e \u003e \u003e - Agenda: https://github.com/ClaraShk/LNJamming/issues/12\n\u003e \u003e \u003e \n\u003e \u003e \u003e # Data Gathering\n\u003e \u003e \u003e During these weekly calls, we've come to agreement that we would like\n\u003e \u003e \u003e to gather data about the use of HTLC endorsement and local reputation\n\u003e \u003e \u003e tracking for jamming mitigation. A reminder of the full scheme is\n\u003e \u003e \u003e included at the end of this email, and covered more verbosely in [1].\n\u003e \u003e \u003e \n\u003e \u003e \u003e We have a few goals in mind:\n\u003e \u003e \u003e - Observe the effect of endorsement in the steady state with\n\u003e \u003e \u003e logging-only implementation.\n\u003e \u003e \u003e - Gather real-world data for use in future simulation work.\n\u003e \u003e \u003e - Experiment with different algorithms for tracking local reputation.\n\u003e \u003e \u003e \n\u003e \u003e \u003e The minimal changes required to add HTLC endorsement are outlined in [2].\n\u003e \u003e \u003e Our suggestion is to start simple with a binary endorsement field. As\n\u003e \u003e \u003e we learn more, we will be better equipped to understand whether a\n\u003e \u003e \u003e more expressive value is required.\n\u003e \u003e \u003e \n\u003e \u003e \u003e With this infrastructure in place, we can start to experiment with\n\u003e \u003e \u003e various local reputation schemes and data gathering, possibly even\n\u003e \u003e \u003e externally to LN implementations in projects like circuitbreaker [3].\n\u003e \u003e \u003e We'd be interested to hear whether there's any appetite to deploy using\n\u003e \u003e \u003e an experimental TLV value?\n\u003e \u003e \u003e \n\u003e \u003e \u003e # Reputation Scheme\n\u003e \u003e \u003e - Each node locally tracks the reputation of its direct neighbors.\n\u003e \u003e \u003e - Each node allocates, per its risk tolerance:\n\u003e \u003e \u003e - A number of slots reserved for endorsed HTLCs from high reputation\n\u003e \u003e \u003e peers.\n\u003e \u003e \u003e - A portion of liquidity reserved for endorsed HTLCs from high\n\u003e \u003e \u003e reputation peers.\n\u003e \u003e \u003e - Forwarding of HTLCs:\n\u003e \u003e \u003e - If a HTLC is endorsed by a high reputation peer, it is forwarded\n\u003e \u003e \u003e as usual with endorsed = 1.\n\u003e \u003e \u003e - Otherwise, it is forwarded with endorsed = 0 if there are slots and\n\u003e \u003e \u003e liquidity available for unknown HTLCs.\n\u003e \u003e \u003e \n\u003e \u003e \u003e Endorsement and reputation are proposed as the first step in a two part\n\u003e \u003e \u003e scheme for mitigating channel jamming:\n\u003e \u003e \u003e - Reputation for slow jams which are easily detected as misbehavior.\n\u003e \u003e \u003e - Unconditional fees for quick jams that are difficult to detect, as\n\u003e \u003e \u003e they can always fall under a target threshold.\n\u003e \u003e \u003e \n\u003e \u003e \u003e Looking forward to discussing further in the upcoming call!\n\u003e \u003e \u003e \n\u003e \u003e \u003e Best,\n\u003e \u003e \u003e Carla and Clara\n\u003e \u003e \u003e \n\u003e \u003e \u003e [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343\n\u003e \u003e \u003e [2] https://github.com/lightning/bolts/pull/1071\n\u003e \u003e \u003e [3] https://github.com/lightningequipment/circuitbreaker\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e \n\u003e \u003e _______________________________________________\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \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"}