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