rich1.0npub1zlxd3xlzjhq2ue03e5m5p2w6mp8v3dkhq5r39flsftjjsje04wvsdd2k4whttps://nostr.ae/npub1zlxd3xlzjhq2ue03e5m5p2w6mp8v3dkhq5r39flsftjjsje04wvsdd2k4wnjumphttps://nostr.ae📅 Original date posted:2022-03-14 📝 Original message: Dear Carsten and fellow lightning developers, thanks for going into such detail and discovering some of the minor inaccuracies of my very rough piecewise linearization! On Mon, Mar 14, 2022 at 1:53 PM Carsten Otto <bitcoin at c-otto.de> wrote: > 1.2) The Mission Control information provided by lnd [...] > > I think you talk a about a maximum available balance of a channel (and > not > > min available balance)? > > Yes, although MC also has information about "known" amounts (due to > failures that only happened further down the road). > I am unsure how mission control stores and handles that data. In my understanding they are mainly interested in a statistic of the ratio of successfull payments over the past X attempts on a channel given a certain time interval. But I assume they should have all the relevant data to produce a proper conditional proability to utilize our learnt knowledge. In any case from the probabilistic model we can do it mathematically precise by just looking at the conditional probabilities. As said I have written hands on instructions in the rust repo https://github.com/lightningdevkit/rust-lightning/issues/1170#issuecomment-972396747 and they have been fully implemented in https://github.com/lightningdevkit/rust-lightning/pull/1227. Also in our mainnet test and simulations we have updated the priors according to those rules and this revealed the full power of the approach. To summarize: Basically we need to know the effective uncertainty by only looking at the effective amount that goes above the minimum certain liquidity (that we might know from a prior attempt) and the effective capacity (somebody recently suggested that conditional capacity might be a better wording) > Assuming that routing nodes indeed do so we would have learnt that neither > > channel has an effective capacity of N. So the combined virtual channel > > could be seen as 2N-1. > > You mean 2(N-1) = 2N-2? > Probably though the difference would be neglectable and if I understood you correctly you will just keep parallel channels separate anyway. > > 4) Leftovers after Piecewise Linearization > > I am not sure if I understand your question / issue here. The splitting > > works by selecting N points on the domain of the function and splitting > the > > domain into segments at those points. This should never leave sats over. > > With quantization of 10,000 a channel of size 123,456 ends up as an arc > with a capacity of 12 units. Cutting this into 5 pieces gives us > 5*2 with 2 units not ending up in any of those pieces. Or am I missing > something here, and we should split into 5 pieces of size 2.4 = 12/5? > Your observation is correct! Indeed I think my code rounds down the capacity instead of going to the correct points and using all of the capacity in the segmentation by making some channels 1 unit larger than others which would happen if actually finding points on the domain to build the segments. This could easily be fixed. However as always: Fully saturated channels mean very low probabilities so even in my situation where I may cut off a significant part of the channel I'd say in the extreme case where we would need to saturate even those sats the flow will and should most likely fail as the min cust is probably just lower than the amount we would attempt to send. Probably opening a new channel or doing an on chain transaction will be more useful. Though of course we should build the piecewise linearization correctly by the end of the day without throughing away some capacity. > If the quantization however makes a channel so small that we cannot > > even create 5 (or N) disjoint segments then I guess the likelihood for > > being included into the final result is too small anyway. > > It may not be very likely, but flat-out ignoring 20k sat (in my > contrived example above) or up to 4*quantization sats (which is the case > you described) doesn't feel right. > See above. I agree it is not 100% accurate. but in practice I doubt it would ever become a problem as this will only be an issue when the payment amount is very close to the min cut which would make flows so unlikely to begin with that we would use other ways to conduct the payment anyway. witch kind regards Rene -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220314/0f59c122/attachment.html>