You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At least for maxflow scaling techniques become more efficient on simple graphs O(nm) instead of O(m^2) as for multi graphs as described in https://youtu.be/7QPI3kBIKv4 at around minute 71 mark.
I propose for maxflow computation we can look at a simple graph by virtualizing multi edges. When creating the actual onion and dissecting the flow into paths we can use the multi graph again
Of course only relevant if the same runtime argument holds in mcf scaling. I guess it will
The text was updated successfully, but these errors were encountered:
Assuming I got my terminology right, I think the implementations that support more than one channel per peer also support some kind of "local multipath" so that they can forward payments that are larger than any single channel they have with a peer, so tis should work.
At least for maxflow scaling techniques become more efficient on simple graphs O(nm) instead of O(m^2) as for multi graphs as described in https://youtu.be/7QPI3kBIKv4 at around minute 71 mark.
I propose for maxflow computation we can look at a simple graph by virtualizing multi edges. When creating the actual onion and dissecting the flow into paths we can use the multi graph again
Of course only relevant if the same runtime argument holds in mcf scaling. I guess it will
The text was updated successfully, but these errors were encountered: