Hi Bastien, I brought up the question about the amounts because it could be that >> amounts high enough to thwart attacks are too high for honest users or >> certain uses. > > > I don't think this is a concern for this proposal, unless there's an > attack vector I missed. > The reason I claim that is that the backwards upfront payment can be made > somewhat big without any > negative impact on honest nodes. >
Yes, that makes sense. > But what happens if the attacker is also on the other end of the >> uncontrolled spam payment? Not holding the payment, but still collecting >> the forward payments? > > > That's what I call short-lived `controlled spam`. In that case the > attacker pays the forward fee at > the beginning of the route but has it refunded at the end of the route. If > the attacker doesn't > want to lose any money, he has to release the HTLC before the grace period > ends (which is going to > be short-lived - at least compared to block times). This gives an > opportunity for legitimate payments > to use the HTLC slots (but it's a race between the attacker and the > legitimate users). > I think indeed that this short-lived controlled spam also needs to be brought under control. Otherwise it is still easy to jam a channel, although it would need a continuous process to do it rather than sending a bunch of 2000-block expiry htlcs. For the short-lived controlled spam there is still a multiplier possible by making loops in the route. It is a race with legitimate users, but if the spammer is efficient the probability of a legitimate payment coming through is low. Similar to DDoS attacks where a legitimate web request could make it to the server but probably doesn't. > It's not ideal, because the attacker isn't penalized...the only way I > think we can penalize this > kind of attack is if the forward fee decrements at each hop, but in that > case it needs to be in the > onion (to avoid probing) and the delta needs to be high enough to actually > penalize the attacker. > Time to bikeshed some numbers! > So in your proposal, an htlc that is received by a routing node has the following properties: * htlc amount * forward up-front payment (anti-spam) * backward up-front payment (anti-hold) * grace period The routing node forwards this to the next hop with * lower htlc amount (to earn routing fees when the htlc settles) * lower forward up-front payment (to make sure that an attacker at the other end loses money when failing quickly) * higher backward up-front payment (to make sure that an attacker at the other end loses money when holding) * shorter grace period (so that there is time to fail back and not lose the backward up-front payment) On a high level, it seems to me that this can actually work. - Joost
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev