ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-11 📝 Original message: Good morning t-bast, > ...

📅 Original date posted:2020-10-11
📝 Original message:
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