{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-19\n📝 Original message:\nGood morning list,\n\nI've started summarizing proposals, attacks and threat models on github [1].\nI'm hoping it will help readers get up-to-speed and avoid falling in the\nsame pitfalls we already\nfell into with previous proposals.\n\nI've kept it very high-level for now; we can add nitty-gritty technical\ndetails as we slowly\nconverge towards acceptable solutions. I have probably missed subtleties\nfrom previous proposals;\nfeel free to contribute to correct my mistakes. I have omitted for examples\nthe details of Rusty's\nprevious proposal since he mentioned a new, better one that will be\ndescribed soon.\n\nWhile doing this exercise, I couldn't find a reason why the `reverse\nupfront payment` proposal\nwould be broken (notice that I described it using a flat amount after a\ngrace period, not an amount\nbased on the time HTLCs are held). Can someone point me to the most obvious\nattacks on it?\n\nIt feels to me that its only issue is that it still allows spamming for\ndurations smaller than the\ngrace period; my gut feeling is that if we add a smaller forward direction\nupfront payment to\ncomplement it it could be a working solution.\n\nPasting it here for completeness:\n\n### Reverse upfront payment\n\nThis proposal builds on the previous one, but reverses the flow. Nodes pay\na fee for *receiving*\nHTLCs instead of *sending* them.\n\n```text\nA -----\u003e B -----\u003e C -----\u003e D\n\nB pays A to receive the HTLC.\nThen C pays B to receive the forwarded HTLC.\nThen D pays C to receive the forwarded HTLC.\n```\n\nThere must be a grace period during which no fees are paid; otherwise the\n`uncontrolled spam` attack\nallows the attacker to force all nodes in the route to pay fees while he's\nnot paying anything.\n\nThe fee cannot be the same at each hop, otherwise it's free for the\nattacker when he is at both\nends of the payment route.\n\nThis fee must increase as the HTLC travels downstream: this ensures that\nnodes that hold HTLCs\nlonger are penalized more than nodes that fail them fast, and if a node has\nto hold an HTLC for a\nlong time because it's stuck downstream, they will receive more fees than\nwhat they have to pay.\n\nThe grace period cannot be the same at each hop either, otherwise the\nattacker can force Bob to be\nthe only one to pay fees. Similarly to how we have `cltv_expiry_delta`,\nnodes must have a\n`grace_period_delta` and the `grace_period` must be bigger upstream than\ndownstream.\n\nDrawbacks:\n\n* The attacker can still lock HTLCs for the duration of the `grace_period`\nand repeat the attack\ncontinuously\n\nOpen questions:\n\n* Does the fee need to be based on the time the HTLC is held?\n* What happens when a channel closes and HTLC-timeout has to be redeemed\non-chain?\n* Can we implement this without exposing the route length to intermediate\nnodes?\n\nCheers,\nBastien\n\n[1] https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md\n\nLe dim. 18 oct. 2020 à 09:25, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e \u003e We've looked at all kinds of trustless payment schemes to keep users\n\u003e\u003e\n\u003e\u003e \u003e honest, but it appears that none of them is satisfactory. Maybe it is\n\u003e\u003e even\n\u003e\u003e \u003e theoretically impossible to create a scheme that is trustless and has\n\u003e\u003e all\n\u003e\u003e \u003e the properties that we're looking for. (A proof of that would also be\n\u003e\u003e\n\u003e\u003e \u003e useful information to have.)\n\u003e\u003e\n\u003e\u003e I don't think anyone has drawn yet a formal proof of this, but roughly a\n\u003e\u003e routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking\n\u003e\u003e to answer the following question \"Is this payment coming from Alice and\n\u003e\u003e going to Caroll will compensate for my resources consumption ?\". With the\n\u003e\u003e current LN system, the compensation is conditional on payment settlement\n\u003e\u003e success and both Alice and Caroll are distrusted yet discretionary on\n\u003e\u003e failure/success. Thus the underscored question is undecidable for a routing\n\u003e\u003e peer making relay decisions only on packet observation.\n\u003e\u003e\n\u003e\u003e One way to mitigate this, is to introduce statistical observation of\n\u003e\u003e sender/receiver, namely a reputation system. It can be achieved through a\n\u003e\u003e scoring system, web-of-trust, or whatever other solution with the same\n\u003e\u003e properties.\n\u003e\u003e But still it must be underscored that statistical observations are only\n\u003e\u003e probabilistic and don't provide resource consumption security to Bob, the\n\u003e\u003e routing peer, in a deterministic way. A well-scored peer may start to\n\u003e\u003e suddenly misbehave.\n\u003e\u003e\n\u003e\u003e In that sense, the efficiency evaluation of a reputation-based solution\n\u003e\u003e to deter DoS must be evaluated based based on the loss of the reputation\n\u003e\u003e bearer related to the potential damage which can be inflicted. It's just\n\u003e\u003e reputation sounds harder to compute accurately than a pure payment-based\n\u003e\u003e DoS protection system.\n\u003e\u003e\n\u003e\n\u003e I can totally see the issues and complexity of a reputation-based system.\n\u003e With 'trustless payment scheme' I meant indeed a trustless pure\n\u003e payment-based DoS protection system and the question whether such a system\n\u003e can be proven to not exist. A sender would pay an up-front amount to cover\n\u003e the maximum cost, but with the guarantee that nodes can only take a fair\n\u003e part of the deposit (based on actual lock time). Perhaps the taproot\n\u003e upgrade offers new possibilities with adaptor signatures to atomically swap\n\u003e part of the up-front payment with htlc-received-in-time-signatures from\n\u003e nodes downstream (random wild idea).\n\u003e\n\u003e\n\u003e\u003e \u003e What I can see working is a system where peers charge each other a hold\n\u003e\u003e fee\n\u003e\u003e \u003e for forwarded HTLCs based on the actual lock time (not the maximum lock\n\u003e\u003e\n\u003e\u003e \u003e time) and the htlc value. This is just for the cost of holding and\n\u003e\u003e separate\n\u003e\u003e \u003e from the routing fee that is earned when the payment settles\n\u003e\u003e\n\u003e\u003e Yes I guess any solution will work as long as it enforces an asymmetry\n\u003e\u003e between the liquidity requester and a honest routing peer. This asymmetry\n\u003e\u003e can be defined as guaranteeing that the routing peer's incoming/outgoing\n\u003e\u003e balance is always increasing, independently of payment success. Obviously\n\u003e\u003e this increase should be materialized by a payment, while minding it might\n\u003e\u003e be discounted based on requester reputation (\"pay-with-your-reputation\").\n\u003e\u003e This reputation evaluation can be fully delegated to the routing node\n\u003e\u003e policy, without network-wise guidance.\n\u003e\u003e\n\u003e\u003e That said, where I'm skeptical on any reputation-heavy system is on the\n\u003e\u003e long-term implications.\n\u003e\u003e\n\u003e\u003e Either, due to the wants of a subset of actors deliberately willingly to\n\u003e\u003e trade satoshis against discounted payment flow by buying well-scored\n\u003e\u003e pubkeys, we see the emergence of a reputation market. Thus enabling\n\u003e\u003e reputation to be fungible to satoshis, but with now a weird \"reputation\"\n\u003e\u003e token to care about.\n\u003e\u003e\n\u003e\u003e Or, reputation is too hard to make liquid (e.g hard to disentangle\n\u003e\u003e pubkeys from channel ownership or export your score across routing peers)\n\u003e\u003e and thus you now have reputation scarcity which is introducing a bias from\n\u003e\u003e a \"purer\" market, where agents are only routing based on advertised fees.\n\u003e\u003e IMO, we should strive for the more liquid Lightning market we can, as it\n\u003e\u003e avoids bias towards past actors and thus may contain centralization\n\u003e\u003e inertia. I'm curious about your opinion on this last point.\n\u003e\u003e\n\u003e\n\u003e I am in favor of more liquidity and less centralization, but as far as I\n\u003e know the reality is that we don't have a good solution yet to achieve this\n\u003e without being vulnerable to DoS attacks. If those attacks would happen on a\n\u003e large scale today, what would we do?\n\u003e\n\u003e Also peers can implement these trusted upfront payments without protocol\n\u003e changes. Just stop forwarding when the prepaid forwarding budget is used up\n\u003e and require a top-up. It may have been implemented already in parts of the\n\u003e network, I don't think there is a way to know. I've experimented a bit with\n\u003e the fee model myself (\n\u003e https://twitter.com/joostjgr/status/1317546071984427009). Node operators\n\u003e don't need to wait for permission.\n\u003e\n\u003e To me it seems that the longer it takes to come up with a good anti-DoS\n\u003e system for Lightning, the further the outside world will have developed\n\u003e their trust-based systems and established that potential bias towards\n\u003e centralization.\n\u003e\n\u003e That might be another reason to prioritize this issue. Not just because we\n\u003e want the network to be safe, but also to be able to implement the preferred\n\u003e solution while the opportunity window is still open.\n\u003e\n\u003e - Joost\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/20201019/93818bf0/attachment.html\u003e"}