Good morning t-bast, > Hey Zman, > > > raising the minimum payment size is another headache > > It's true that it may (depending on the algorithm) lower the success rate of > MPP-split. > But it's already a parameter that node operators can configure at will (at > channel creation time), > so IMO it's a complexity we have to deal with anyway. Making it dynamic > shouldn't have a high > impact on MPP algorithms (apart from failures while `channel_update`s are > propagating).
Right, it should not have much impact. For the most part, when considering the possibility of splicing in the future, we should consider that such parameters must be made changeable largely. > > To be fully honest, my (maybe unpopular) opinion about MPP is that it's not > necessary on the > network's backbone, only at its edges. Once the network matures, I expect > channels between > "serious" routing nodes to be way bigger than the size of individual > payments. The only places > where there may be small or almost-empty channels are between end-users > (wallets) and > routing nodes. > If something like Trampoline were to be implemented, MPP would only be needed > to reach a > first routing node (short route), that routing node would aggregate the parts > and forward as a > single HTLC to the next routing node. It would be split again once it reaches > the other edge > of the network (for a short route as well). In a network like this, the MPP > routes would only have > to be computed on a small subset of the network, which makes brute-force > algorithms completely > reasonable and the success rate higher. This makes me wonder if we really need the onions-per-channel model we currently use. For instance, Tor is basically two-layer: there is a lower-level TCP/IP layer where packets are sent out to specific nodes on the network and this layer is completely open about where the packet should go, but there is a higher layer where onion routing between nodes is used. We could imitate this, with HTLC packets that openly show the next destination node, but once all parts reach the destination node, it decodes and turns out to be an onion to be sent to the next destination node, and the current destination node is just another forwarder. HTLC packets could be split arbitrarily, and later nodes could potentially merge with the lower CLTV used in subsequent hops. Or not, *shrug*. It has the bad problem of being more expensive on average than purely source-based routing, and probably having worse payment latency. For your proposal, how sure is the receiver that the input end of the trampoline node is "nearer" to the payer than itself? Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
