Rusty Russell <ru...@rustcorp.com.au> writes: > Jim Posen <jim.po...@gmail.com> writes: > If failure is common this would be true, but I think it's too early to > design for it. > > This kind of signalling is what fees are for: when capacity gets low you > increase fees, and when it gets high, you reduce them. But that may > still prove insufficient. > > Two things come to mind: > > 1. `temporary_channel_failure` returns a `channel_update`. The > implication is that this has the disabled flag, but we should > probably make that true iff the request asks for < 2% of the channel > capacity or some "minimal bar". If you can't even service this, you > should disable the channel. > > 2. We can implement fast failure to reduce latency: > https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming > > Note that there needs to be more analysis on reliable ways to mask the > active capacity of a channel: using a static random threshold still > leaks information that *something* has happened, so it may need to be > more sophisticated.
I have to agree with Rusty here, pinging a channel for capacity sounds a lot like premature optimization. In addition it could lead to a rather large privacy leak, both for the sender as well as the individual channels. Giving any information about the current balance of a channel, could lead to tracing payments through the network. And users pinging channels before making a payment could result also in traced payments. The feedback mechanism we have by adding channel_updates in the failure message should allow senders to learn about changes in the channels that caused the failure, and it should be injected into the gossip so peers learn about it as well. Once we have exhausted what we can do with the simple gossip mechanism, only then should we be looking at other solutions. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
