From john-john at markstedts.org Thu Mar 14 07:58:18 2019 From: john-john at markstedts.org (John-John Markstedt) Date: Thu, 14 Mar 2019 08:58:18 +0100 Subject: [Lightning-dev] Fee structure In-Reply-To: References: Message-ID: Good morning Andrea and ZmnSCPxj, I wrongly assumed the channel balances needed to be known anyway to create a route. I see now why that is not the case and why it would scale horribly, in fact it scales no better than layer 1 as everyone needs to be notified of every payment. It would also defeat effort of keeping payments private. This is clearly the wrong line of thinking. This is already possible within the protocol. > Care must be taken that `channel_update` is not spammed, which potentially > leaks information about payments passing through the node. > A simple heuristic would be to have a random schedule of checking the > channel current state, sending a `channel_update` if the feerate should be > changed, then sleeping for a random number of seconds before checking again. > This will get you reasonably close to what you want, without too much > leakage of payments going through you. > That would not regard the size of the payments though? A payment leaving the balance at the far end would pay the same proportional fee as one close to the middle. Again fixing that issue by broadcasting each balance change wouldn't scale well and run in the aforementioned leakage so is really a moot point. I don't see setting the fee only regarding the initial state as obviously beneficial to a routing node, anyway it would indeed be interesting to see if a node utilizing such a strategy, all else being equal, would outperform a node not using it. I will implement something along this line and see it that's the case or not. JIT Routing from rpickhardt is more sensible as it attempts to rebalance > only if it would benefit the node to perform the rebalancing. > (It is more accurately named "JIT rebalancing" actually) > I will have another closer look at the JIT Routing emails. - Thanks both of you for taking the time to respond and pointing out the clear flaws in this idea. Best regards, John-John Markstedt -------------- next part -------------- An HTML attachment was scrubbed... URL: