{"type":"rich","version":"1.0","author_name":"npub1tcwr7j30p5q4sypnsw4arca9s2433s7wdcpt2z2sk7pkqfsntjds0pu5xp","author_url":"https://nostr.ae/npub1tcwr7j30p5q4sypnsw4arca9s2433s7wdcpt2z2sk7pkqfsntjds0pu5xp","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-03-02\n📝 Original message:\nHello,\n\nI think the local reputation is more important than upfront fees and should\nbe worked on first because 1) the most likely attack against the network\ntoday is the slow jamming attack against which upfront fees are not very\neffective (an attacker would only consider fast jamming if the network is\nalready resilient to slow jamming) and 2) I think that local reputation may\nprotect well enough against all types of jamming so that we don't even need\nupfront fees to protect against fast jamming.\nRegarding the formula itself, I would treat all scores as continuous values\nbetween 0 and 1 instead of binary classes. My proposed formula is detailed\nhere:\nhttps://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing\nHowever my proposal is compatible with Clara's one in that the only thing\nthat needs to be communicated to the peers is how confident we are that the\npayment will succeed and all the rest is done locally and everyone can use\ntheir own formula. I would just prefer this confidence value to be more\nthan one bit but my formula would work with anything, even zero bits. The\nadvantage of using more bits is that we can be more precise in which HTLCs\nwe reject and reduce the number of innocent casualties.\n\nThomas\n\nLe jeu. 16 févr. 2023 à 22:29, Clara Shikhelman \u003cclara.shikhelman at gmail.com\u003e\na écrit :\n\n\u003e Hi List,\n\u003e\n\u003e We’re writing to seek early feedback on a draft for a neighbour reputation\n\u003e setting recommendation as a jamming mitigation. The main idea is that\n\u003e allowing full access to liquidity and slots in a channel can result in\n\u003e jamming. To prevent this, we allow full access only to neighbours that\n\u003e forward HTLC that resolve quickly and generate more profit than the damage\n\u003e they can potentially create.\n\u003e\n\u003e The full suggested jamming mitigation solution includes upfront fees\n\u003e together with reputation, see [1] for details.\n\u003e\n\u003e In the previous episodes:\n\u003e\n\u003e As presented here [1], we suggest a two part jamming mitigation strategy.\n\u003e Reputation-based forwarding is aimed to solve “slow jamming”, where the\n\u003e jamming transaction takes a long time to resolve.\n\u003e\n\u003e The main idea is that each node gives a binary reputation to its\n\u003e neighbour. Each channel has a quota of liquidity and slots (say 50% of the\n\u003e channel size and 50% of the slots in the channel) dedicated to transactions\n\u003e coming from neighbours with reputation 0, or for transactions coming from\n\u003e neighbours with reputation 1 that were not endorsed by the neighbour.\n\u003e\n\u003e For example, when Alice asks Bob to forward to Charlie then:\n\u003e\n\u003e If (Alice has reputation 1 with Bob) and (Alice endorses transaction):\n\u003e\n\u003e Forward and endorse\n\u003e\n\u003e Else:\n\u003e\n\u003e If (amount \u003c available liquidity quota) and (available slots in quota\u003e0):\n\u003e\n\u003e Forward HTLC without endorsing\n\u003e\n\u003e Reduce available liquidity and slots\n\u003e\n\u003e Else:\n\u003e\n\u003e Reject\n\u003e\n\u003e Reputation:\n\u003e\n\u003e The question we discuss here is how does Alice gain “good” reputation\n\u003e (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good\n\u003e reputation of 1 by continuously paying more fees to Bob than the damage she\n\u003e can inflict.\n\u003e\n\u003e The 3 main parameters for reputation that each node operator picks are S,L\n\u003e and M. Our recommendations are as follows:\n\u003e\n\u003e    -\n\u003e\n\u003e    S should be chosen as the maximum time an HTLC can be unresolved in\n\u003e    any of Bob’s channels.\n\u003e    -\n\u003e\n\u003e    M is the revenue generated by Bob’s node in the time S, representing\n\u003e    the damage Alice could inflict.\n\u003e    -\n\u003e\n\u003e    L is the time in which Alice should generate M revenue for Bob for her\n\u003e    to have a good reputation of 1. We suggest L=10S.\n\u003e\n\u003e\n\u003e Alice has reputation 1 if, in the last L seconds, she has forwarded\n\u003e payments that generated M satoshi in fees.\n\u003e\n\u003e As an example:\n\u003e\n\u003e    -\n\u003e\n\u003e    Bob has a maximum CLTV delta of 2 weeks [2]\n\u003e    -\n\u003e\n\u003e    Over the last 2 weeks, he has earned 0.5 BTC in routing fees\n\u003e    -\n\u003e\n\u003e    Alice will be considered to have good reputation if she has forwarded\n\u003e    0.5 BTC of routing revenue to Bob over the last 20 weeks\n\u003e\n\u003e\n\u003e Formally:\n\u003e\n\u003e Let t be the current time, and let S and L be constants.\n\u003e\n\u003e M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of\n\u003e Bob is the sum of fees from transactions forwarded by any neighbour besides\n\u003e Alice + any payments received by Bob. Note that Bob can choose to also take\n\u003e into account utility gained from sending payments or anything of value to\n\u003e the node operator.\n\u003e\n\u003e Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs\n\u003e that paid M in normalized fees.\n\u003e\n\u003e We normalize fees by resolution time to reward payments that resolve\n\u003e quickly and discount slow resolving payments. Here we assume 10 seconds is\n\u003e the “normal” resolution time, this number can be bikesheded, and we round\n\u003e up to avoid penalizing transactions resolved quicker than the “normal”.\n\u003e\n\u003e The fee from a single transaction is normalized by the time it took for\n\u003e the HTLC to resolve, counted in slots of 10 seconds. That is:\n\u003e\n\u003e Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)]\n\u003e\n\u003e\n\u003e\n\u003e Some notes\n\u003e\n\u003e    1.\n\u003e\n\u003e    The reputation management happens locally, that is, the only protocol\n\u003e    change needed is the ability to signal endorsement as a TLV in\n\u003e    UpdateAddHTLC. The various parameters can be selected for various risk\n\u003e    preferences.\n\u003e    2.\n\u003e\n\u003e    We currently suggest a binary reputation for simplicity. Having\n\u003e    several buckets could be interesting to study, yet we don’t think that the\n\u003e    complexity and the possible privacy issues are worth the potential benefits.\n\u003e    3.\n\u003e\n\u003e    For most use cases, having reputation 0 is more than enough. If we\n\u003e    send and receive transactions at a low rate, we usually don’t need the full\n\u003e    liquidity and slots available in a channel. Reputation mostly comes into\n\u003e    play only when a channel is under attack, and then not all transaction are\n\u003e    allowed to go through.\n\u003e    4.\n\u003e\n\u003e    Following this thread [3]: it is important to note that we are only\n\u003e    giving reputation to our direct neighbours. An advantage of this is that we\n\u003e    have repeated interactions with them. In practice, this is also the only\n\u003e    clean data we have to use when deciding whether to forward an HTLC or not.\n\u003e\n\u003e\n\u003e Best,\n\u003e\n\u003e Carla and Clara\n\u003e\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html\n\u003e [2]\n\u003e https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51\n\u003e [3]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html\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/20230302/47bf0566/attachment-0001.html\u003e"}