> > It is interesting that the forward and backward payments are relatively >> independent of each other > > > To explain this further, I think it's important to highlight that the > forward fee is meant to fight > `uncontrolled spam` (where the recipient is an honest node) while the > backward fee is meant to fight > `controlled spam` (where the recipient also belongs to the attacker). >
Yes, that was clear. I just meant to say that we could choose to first only implement the easier uncontrolled spam protection via the forward payment. Not that any type of protocol upgrade is easy... What I'd really like to explore is whether there is a type of spam that I > missed or griefing attacks > that appear because of the mechanisms I introduce. TBH I think the > implementation details (amounts, > grace periods and their deltas, when to start counting, etc) are things > we'll be able to figure out > collectively later. > 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. If that is the case, we don't need to look for other potential weaknesses. It is just a different order to explore the feasibility of the proposal. The forward payment can indeed be small, because uncontrolled spam can only be in-flight for a short time. To get to that annual return of 5% on a 1 BTC / 483 slot channel, it needs to be approx 1 sat/hour (if I calculated that correctly). Let's say the spam payment is in-flight on average 30 seconds on a 20 route hop (60 sec at the start, 0 sec at the end). The total "damage" would then be 600 hop-seconds, requiring a forward payment of 150 msat to cover that. Still seems acceptable to me. If an honest user makes a payment and needs 10 attempts, they will pay an additional 1.5 sats for that. Might be a ux-challenge to communicate that cost to a normal user for a failed payment though. 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? For the backward payment the pricing is different. The max expiry of the htlc is 2000 blocks, 1000 blocks on average along the route. 1000 blocks is about 160 hours. So ideally the attacker at the far end of the route should pay 20 * 160 * 1sat/hr = 3200 sat. This will also be the cost for a hold invoice then, but not everybody liked them anyway. The net cost for a regular (fast) payment will be nothing as you described. - Joost >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev