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