{"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:\nTo give a very simple example, imagine a node that sends the same\nconfidence c for all HTLCs. We want c to be equal to the probability p that\nits HTLCs succeed.\n- If c = p then all is well and we give a reputation of 1 to the node.\n- If c \u003e p then this node is overconfident or is lying to have its HTLCs\nrelayed, in both cases we should lower its reputation to account for that.\n- If c \u003c p then yes it gives it a higher reputation but the reputation is\ncapped at 1 anyway, so by underestimating the confidence the node doesn't\ngain anything.\nIdeally we want all honest nodes to have a reputation of 1. It doesn't mean\nthat all their HTLCs succeed, it just means that they provide reliable\nestimates of the success probability of the HTLCs.\n\nLe jeu. 2 mars 2023 à 19:57, Clara Shikhelman \u003cclara.shikhelman at gmail.com\u003e\na écrit :\n\n\u003e Hi Thomas,\n\u003e\n\u003e I really like the idea of taking into consideration the failures. In our\n\u003e proposal, a failure won't benefit your reputation, as the neighbour is\n\u003e trying to reach a fee threshold, but taking it into account instead of\n\u003e ignoring it could be helpful against an adversary trying to manipulate\n\u003e parameters.\n\u003e\n\u003e Could you elaborate a bit about \"*c, the confidence given by the previous\n\u003e node.*\" It looks from the formula (that has *1/c* component) that the\n\u003e lower the confidence, the higher the reputation, and I am not sure that\n\u003e this is the goal. Some numerical examples could help clarify the dynamics\n\u003e you are aiming for.\n\u003e\n\u003e Do you have some estimation of what kind of protection or compensation\n\u003e this method offers?\n\u003e\n\u003e Best,\n\u003e Clara\n\u003e\n\u003e On Thu, Mar 2, 2023 at 8:14 AM Thomas HUET \u003cthomas.huet at acinq.fr\u003e wrote:\n\u003e\n\u003e\u003e Hello,\n\u003e\u003e\n\u003e\u003e I think the local reputation is more important than upfront fees and\n\u003e\u003e should be worked on first because 1) the most likely attack against the\n\u003e\u003e network today is the slow jamming attack against which upfront fees are not\n\u003e\u003e very effective (an attacker would only consider fast jamming if the network\n\u003e\u003e is already resilient to slow jamming) and 2) I think that local reputation\n\u003e\u003e may protect well enough against all types of jamming so that we don't even\n\u003e\u003e need upfront fees to protect against fast jamming.\n\u003e\u003e Regarding the formula itself, I would treat all scores as continuous\n\u003e\u003e values between 0 and 1 instead of binary classes. My proposed formula is\n\u003e\u003e detailed here:\n\u003e\u003e\n\u003e\u003e https://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing\n\u003e\u003e However my proposal is compatible with Clara's one in that the only thing\n\u003e\u003e that needs to be communicated to the peers is how confident we are that the\n\u003e\u003e payment will succeed and all the rest is done locally and everyone can use\n\u003e\u003e their own formula. I would just prefer this confidence value to be more\n\u003e\u003e than one bit but my formula would work with anything, even zero bits. The\n\u003e\u003e advantage of using more bits is that we can be more precise in which HTLCs\n\u003e\u003e we reject and reduce the number of innocent casualties.\n\u003e\u003e\n\u003e\u003e Thomas\n\u003e\u003e\n\u003e\u003e Le jeu. 16 févr. 2023 à 22:29, Clara Shikhelman \u003c\n\u003e\u003e clara.shikhelman at gmail.com\u003e a écrit :\n\u003e\u003e\n\u003e\u003e\u003e Hi List,\n\u003e\u003e\u003e\n\u003e\u003e\u003e We’re writing to seek early feedback on a draft for a neighbour\n\u003e\u003e\u003e reputation setting recommendation as a jamming mitigation. The main idea is\n\u003e\u003e\u003e that allowing full access to liquidity and slots in a channel can result in\n\u003e\u003e\u003e jamming. To prevent this, we allow full access only to neighbours that\n\u003e\u003e\u003e forward HTLC that resolve quickly and generate more profit than the damage\n\u003e\u003e\u003e they can potentially create.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The full suggested jamming mitigation solution includes upfront fees\n\u003e\u003e\u003e together with reputation, see [1] for details.\n\u003e\u003e\u003e\n\u003e\u003e\u003e In the previous episodes:\n\u003e\u003e\u003e\n\u003e\u003e\u003e As presented here [1], we suggest a two part jamming mitigation\n\u003e\u003e\u003e strategy. Reputation-based forwarding is aimed to solve “slow jamming”,\n\u003e\u003e\u003e where the jamming transaction takes a long time to resolve.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The main idea is that each node gives a binary reputation to its\n\u003e\u003e\u003e neighbour. Each channel has a quota of liquidity and slots (say 50% of the\n\u003e\u003e\u003e channel size and 50% of the slots in the channel) dedicated to transactions\n\u003e\u003e\u003e coming from neighbours with reputation 0, or for transactions coming from\n\u003e\u003e\u003e neighbours with reputation 1 that were not endorsed by the neighbour.\n\u003e\u003e\u003e\n\u003e\u003e\u003e For example, when Alice asks Bob to forward to Charlie then:\n\u003e\u003e\u003e\n\u003e\u003e\u003e If (Alice has reputation 1 with Bob) and (Alice endorses transaction):\n\u003e\u003e\u003e\n\u003e\u003e\u003e Forward and endorse\n\u003e\u003e\u003e\n\u003e\u003e\u003e Else:\n\u003e\u003e\u003e\n\u003e\u003e\u003e If (amount \u003c available liquidity quota) and (available slots in\n\u003e\u003e\u003e quota\u003e0):\n\u003e\u003e\u003e\n\u003e\u003e\u003e Forward HTLC without endorsing\n\u003e\u003e\u003e\n\u003e\u003e\u003e Reduce available liquidity and slots\n\u003e\u003e\u003e\n\u003e\u003e\u003e Else:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Reject\n\u003e\u003e\u003e\n\u003e\u003e\u003e Reputation:\n\u003e\u003e\u003e\n\u003e\u003e\u003e The question we discuss here is how does Alice gain “good” reputation\n\u003e\u003e\u003e (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good\n\u003e\u003e\u003e reputation of 1 by continuously paying more fees to Bob than the damage she\n\u003e\u003e\u003e can inflict.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The 3 main parameters for reputation that each node operator picks are S,L\n\u003e\u003e\u003e and M. Our recommendations are as follows:\n\u003e\u003e\u003e\n\u003e\u003e\u003e    -\n\u003e\u003e\u003e\n\u003e\u003e\u003e    S should be chosen as the maximum time an HTLC can be unresolved in\n\u003e\u003e\u003e    any of Bob’s channels.\n\u003e\u003e\u003e    -\n\u003e\u003e\u003e\n\u003e\u003e\u003e    M is the revenue generated by Bob’s node in the time S, representing\n\u003e\u003e\u003e    the damage Alice could inflict.\n\u003e\u003e\u003e    -\n\u003e\u003e\u003e\n\u003e\u003e\u003e    L is the time in which Alice should generate M revenue for Bob for\n\u003e\u003e\u003e    her to have a good reputation of 1. We suggest L=10S.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Alice has reputation 1 if, in the last L seconds, she has forwarded\n\u003e\u003e\u003e payments that generated M satoshi in fees.\n\u003e\u003e\u003e\n\u003e\u003e\u003e As an example:\n\u003e\u003e\u003e\n\u003e\u003e\u003e    -\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Bob has a maximum CLTV delta of 2 weeks [2]\n\u003e\u003e\u003e    -\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Over the last 2 weeks, he has earned 0.5 BTC in routing fees\n\u003e\u003e\u003e    -\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Alice will be considered to have good reputation if she has\n\u003e\u003e\u003e    forwarded 0.5 BTC of routing revenue to Bob over the last 20 weeks\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Formally:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Let t be the current time, and let S and L be constants.\n\u003e\u003e\u003e\n\u003e\u003e\u003e M is calculated to be the revenue of Bob in time [t-S,t]. The revenue\n\u003e\u003e\u003e of Bob is the sum of fees from transactions forwarded by any neighbour\n\u003e\u003e\u003e besides Alice + any payments received by Bob. Note that Bob can choose to\n\u003e\u003e\u003e also take into account utility gained from sending payments or anything\n\u003e\u003e\u003e of value to the node operator.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs\n\u003e\u003e\u003e that paid M in normalized fees.\n\u003e\u003e\u003e\n\u003e\u003e\u003e We normalize fees by resolution time to reward payments that resolve\n\u003e\u003e\u003e quickly and discount slow resolving payments. Here we assume 10 seconds is\n\u003e\u003e\u003e the “normal” resolution time, this number can be bikesheded, and we round\n\u003e\u003e\u003e up to avoid penalizing transactions resolved quicker than the “normal”.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The fee from a single transaction is normalized by the time it took for\n\u003e\u003e\u003e the HTLC to resolve, counted in slots of 10 seconds. That is:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)]\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Some notes\n\u003e\u003e\u003e\n\u003e\u003e\u003e    1.\n\u003e\u003e\u003e\n\u003e\u003e\u003e    The reputation management happens locally, that is, the only\n\u003e\u003e\u003e    protocol change needed is the ability to signal endorsement as a TLV\n\u003e\u003e\u003e    in UpdateAddHTLC. The various parameters can be selected for various\n\u003e\u003e\u003e    risk preferences.\n\u003e\u003e\u003e    2.\n\u003e\u003e\u003e\n\u003e\u003e\u003e    We currently suggest a binary reputation for simplicity. Having\n\u003e\u003e\u003e    several buckets could be interesting to study, yet we don’t think that the\n\u003e\u003e\u003e    complexity and the possible privacy issues are worth the potential benefits.\n\u003e\u003e\u003e    3.\n\u003e\u003e\u003e\n\u003e\u003e\u003e    For most use cases, having reputation 0 is more than enough. If we\n\u003e\u003e\u003e    send and receive transactions at a low rate, we usually don’t need the full\n\u003e\u003e\u003e    liquidity and slots available in a channel. Reputation mostly comes into\n\u003e\u003e\u003e    play only when a channel is under attack, and then not all transaction are\n\u003e\u003e\u003e    allowed to go through.\n\u003e\u003e\u003e    4.\n\u003e\u003e\u003e\n\u003e\u003e\u003e    Following this thread [3]: it is important to note that we are only\n\u003e\u003e\u003e    giving reputation to our direct neighbours. An advantage of this is that we\n\u003e\u003e\u003e    have repeated interactions with them. In practice, this is also the only\n\u003e\u003e\u003e    clean data we have to use when deciding whether to forward an HTLC or not.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Best,\n\u003e\u003e\u003e\n\u003e\u003e\u003e Carla and Clara\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e [1]\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html\n\u003e\u003e\u003e [2]\n\u003e\u003e\u003e https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51\n\u003e\u003e\u003e [3]\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html\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\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230302/f66062bc/attachment-0001.html\u003e"}