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
The PaymentSession consists usually of a payment loop and sends out attempts either synchronously (mostely for simulations) or concurrently (in mainnet). It seems as if the min cost flow computation is part of a payment. Thus we might regactor some things into the Payment class and have it very concise and shielded.
A counter argument would be that the min cost clow solver with the new Library by @Lagrang3 will store the uncertainty network and maintain the arcs of the solver for the next round of computation during the payment session. In that sense it seems reasonable that the solver lives outside the payments but within the session.
On the other hand the beauty of moving the solver would be that the payment would be responsible for planning the payment independently how the loop is handeling and updating everything.
Looking forward to also have the discussion with @sebulino
The text was updated successfully, but these errors were encountered:
If you ask me, a PaymentSession is not able to send out attempts it only does computation. The user feeds the PaymentSession with the information it gets from a LN node (or a simulation), then retrieves the MPP that the session suggests and this MPP is then forwarded back to LN to try a payment, and this process is iterative.
We don't know a priori which will be the LN oracle, and we shouldn't care because that is not our job.
Maybe I am confused because you understand payment what I call PaymentSession, while for you a PaymentSession is a simulation of how payment works. I think we should clarify these concepts.
The
PaymentSession
consists usually of a payment loop and sends out attempts either synchronously (mostely for simulations) or concurrently (in mainnet). It seems as if the min cost flow computation is part of apayment
. Thus we might regactor some things into thePayment class
and have it very concise and shielded.A counter argument would be that the min cost clow solver with the new Library by @Lagrang3 will store the uncertainty network and maintain the arcs of the solver for the next round of computation during the payment session. In that sense it seems reasonable that the solver lives outside the payments but within the session.
On the other hand the beauty of moving the solver would be that the payment would be responsible for planning the payment independently how the loop is handeling and updating everything.
Looking forward to also have the discussion with @sebulino
The text was updated successfully, but these errors were encountered: