From rusty at rustcorp.com.au Tue Oct 13 03:05:39 2020 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 13 Oct 2020 13:35:39 +1030 Subject: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself In-Reply-To: References: Message-ID: <87d01mlta4.fsf@rustcorp.com.au> Joost Jager writes: > This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value). > fee_base is in there to compensate for the usage of an htlc slot, which is > a scarce resource too. ... > > In both cases the sender needs to trust its peer to not steal the payment > and/or artificially delay the forwarding to inflate the hold fee. I think > that is acceptable given that there is a trust relation between peers > already anyway. > > A crucial thing is that these hold fees don't need to be symmetric. A new > node for example that opens a channel to a well-known, established routing > node will be forced to pay a hold fee, but won't see any traffic coming in > anymore if it announces a hold fee itself. Nodes will need to build a > reputation before they're able to command hold fees. Similarly, routing > nodes that have a strong relation may decide to not charge hold fees to > each other at all. I can still establish channels to various low-reputation nodes, and then use them to grief a high-reputation node. Not only do I get to jam up the high-reputation channels, as a bonus I get the low-reputation nodes to pay for it! Operators of high reputation nodes can even make this profitable; doubly so, since they eliminate the chance of any of those low-reputation nodes every getting to be high reputation (and thus competing). AFAICT any scheme which penalizes the direct peer creates a bias against forwarding unknown payments, thus is deanonymizing. > I'd also like to encourage everyone to prioritize this spam/jam issue and > dedicate more time to solving it. Obviously there is a lot more to do in > Lightning, but I am not sure if we can afford to wait for the real > adversaries to show up on this one. Agreed. It's a classic "it's not actually on fire *right now*" problem, so it does keep getting pushed back. Cheers, Rusty.