{"type":"rich","version":"1.0","author_name":"npub13fccestrh5xf26m53n73xn5yly9z040a4n9vq30mernkj0cqszuq9tgaqs","author_url":"https://nostr.ae/npub13fccestrh5xf26m53n73xn5yly9z040a4n9vq30mernkj0cqszuq9tgaqs","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-03-13\n📝 Original message:\nHi Rene,\n\nthanks a lot for your contribution! This is exactly what I needed to\nstart coding again :) I intend to release a somewhat usable version of\nyour approach in lnd-manageJ [1] soon. Preliminary results indicate that\nresults (i.e. MPPs to try) can be computed in less than a second, which\nis great!\n\nImportant remark: my code can only be used for real MPPs once a usable\nMPP gRPC call is made available, see lnd issue #5746 [2].\n\nWhile working on my implementation, a few questions came to mind:\n\n1) What's the reasoning behind combining parallel channels?\n\nI agree that parallel channels make things a lot more complicated, but I\nalso see the benefit from a node operator's point of view. That being\nsaid, wouldn't it suffice to treat parallel channels individually?\n\n1.1) A payment of size 2 needs to be split into 1+1 to fit through\nparallel channels of size 1+1. Combining the 1+1 channels into a virtual\nchannel of size 2 only complicates the code that has to do come up with\na MPP that doesn't over-saturate the actual channels. On the other hand,\nI don't think the probability for the virtual channel of size 2 is more\nrealistic than reasoning about two individual channels and their\nprobabilities - but I didn't even try to see the math behind that.\nPlease prove me wrong? :)\n\n1.2) The Mission Control information provided by lnd can be used to\nplace a minimum available balance on each of the parallel channels. If\nwe know that node A isn't able to forward N sats to node B, we can treat\nall parallel channels between A and B (in that direction) to have a\ncapacity of at most N-1 sats. How would this look like if we combined\nthe parallel channels into a virtual one? Note that it may still be\npossible to route two individual payments/onions of size N-1 sats from A\nto B, given two parallel channels with that many sats on A's side.\n\n2) Optimal Piecewise Linearization\n\nSee Twitter [3].\n\nIs it worth it cutting a channel into pieces of different sizes, instead\nof just having (as per your example) 5 pieces of the same size? If it\nmakes a noticeable difference, adding some complexity to the code might\nbe worth it.\n\n3) Size of Piecewise Linearization\n\nMy gut feeling is that cutting a 1 BTC channel into 5 pieces is\ndifferent from cutting a 0.01 BTC channel into 5 pieces. Would it make\nsense to use different values of N depending on the channel size?\n\n4) Leftovers after Piecewise Linearization\n\nIf I cut some channel into N pieces, I might end up with up to N-1 sats\nthat don't end up in any of the N pieces, effectively making the channel\nlook smaller than it is. For smaller values of N that's obviously not an\nissue (given the uncertainty we're dealing with), but it might be more\nproblematic if quantization is used with larger values. Any thoughts on\nthis?\n\n5) Fees (and other properties?)\n\nHow can we integrate fees into the function? I must admit, I haven't\neven thought about that, yet. A copy-paste answer would be great,\nthough! :) Maybe it's also a good idea to punish channels based on their\nCLTV delta? Ratio of enabled channels? Age? Manual punishment score? ...\n\n6) Non-Zero Base Fee\n\nSee Twitter [4].\n\nAccording to Stefan [5] it should be possible to integrate ZmnSCPxj's ideas\nto make this work with non-zero base fees. How?\nSimpler approach: Twitter [6].\n\n7) Private Channels\n\n[very niche topic, not really that interesting nor urgent]\n\nI'm a fan of adding private channels to provide more outbound liquidity,\nmainly to reduce gossip and hide my intentions. If my total liquidity to\nsome peer is below the amount announced in public channels, I don't see\nany meaningful complication. However, I might have a public channel of\nsize N and several private channels bringing my local liquidity to some\nvalue \u003eN. It's rather obvious that not announcing this fact is a bad\nidea, as any #pickhardtpayments implementation would think I have 0-N on\nmy side of the channel(s). Assuming I'm willing to accept this tradeoff,\ndo you see other complications or issues with hidden liquidity?\n\nMy gut feeling is that this isn't an issue, at all, as channel balances\nchange all the time, which is something the algorithm already has to\ndeal with.\n\n8) Quality of Approximation\n\nThere are some problems in computer science that are hard/impossible to\napproximate, in the sense that any kind of deviation from the optimum\ncould cause the computed results to be extremely bad. Do you have some\nidea (or proof) that your kind of approximation isn't causing a major\nissue? I guess a piece-wise linearization with an infinite number of\npieces corresponds to the optimal result. Given a finite number of\npieces, how large is the difference to the optimum?\n\nBye,\nCarsten\n\n1: https://github.com/C-Otto/lnd-manageJ/issues/6\n2: https://github.com/lightningnetwork/lnd/issues/5746\n3: https://twitter.com/c_otto83/status/1502329970349248521\n4: https://twitter.com/c_otto83/status/1502329271964033027\n5: https://twitter.com/stefanwouldgo/status/1502681455918473217\n6: https://twitter.com/c_otto83/status/1502330558793363464\n-- \nDr. Carsten Otto\ncarsten at c-otto.de\nhttps://c-otto.de\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 195 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220313/1437e67a/attachment.sig\u003e"}