Extraction of Attempt and Payment. A Payment is a central object in the library, and in particular in the simulation. This is why it "deserves" its own Class. Each onion is recorded as an Attempt and registered with the respective Payment. This not only allows for statistics for each Payment object but also collects all attempts where an amount could successfully flow from sender to receiver.

refactoring of SyncSimulatedPaymentSession has been done as well as a first version of the documentation of the two classes.

As people get familiar with Pickhardt Payments and how they work, it should be easier for them to follow along when they come across this repo. Hence,I thought it necessary to clear up some grammatical issues in the documentation.

Template to include the simulation of payments on the ChannelGraph, extending the previous single period model to a multi period model.

Not included is the Channel Graph "listchannels20220412.json", residing in repo root.

It seems like this merged pull request broke the payment algorithm or simulation:

https://github.com/renepickhardt/pickhardtpayments/pull/24

PickhardtPaymentsExample.ipynb examples don't work anymore:

Round number: 10 Try to deliver 18879883 satoshi:

Statistics about 46 candidate onions:

successful attempts:

p = 100.00% amt: 216543 sats hops: 4 ppm: 1413 p = 94.37% amt: 84263 sats hops: 5 ppm: 1349 p = 90.69% amt: 59164 sats hops: 5 ppm: 1708 p = 75.00% amt: 337453 sats hops: 5 ppm: 1417 p = 73.91% amt: 112351 sats hops: 5 ppm: 1374 p = 99.52% amt: 42718 sats hops: 6 ppm: 1348 p = 100.00% amt: 35946 sats hops: 6 ppm: 1367 p = 94.97% amt: 242846 sats hops: 7 ppm: 1696 p = 77.42% amt: 2351 sats hops: 9 ppm: 1427

failed attempts:

p = 100.00% amt: 88000 sats hops: 2 ppm: 1339 p = 74.25% amt: 288187 sats hops: 2 ppm: 1341 p = 14.57% amt: 1574652 sats hops: 2 ppm: 1359 p = 100.00% amt: 102400 sats hops: 2 ppm: 1381 p = 100.00% amt: 102400 sats hops: 2 ppm: 1356 ....

SUMMARY:

Rounds of mcf-computations: 10 Number of attempts made: 448 Number of failed attempts: 356 Failure rate: 79.46% total Payment lifetime (including inefficient memory management): 8.661 sec Learnt entropy: 229.60 bits fee for settlement of delivery: 0.000 sat --> 0 ppm used mu: 100

It's possible that in the Channel Graph there's only information about one channel and information about its return channel is missing. Consequently they are currently not created in the UncertaintyNetwork (and possibly the OracleNetwork).

For the UncertaintyNetwork we still have enough information to create the return channel with a good enough estimate. Thus we should create them if needed. This could be done in the constructor or when the getter is called and would return none.

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

We merged PR #24 so that we can focus on #18 . But it became clear that some of the refactoring is not fully completed yet. In particular it seems important to introduce a Path classe which wraps a list of UncertaintyChannels.

Hi @renepickhardt. I have prepared a draft for the C-API. I still owe you an example, I'll work on that.

I'm also proposing an example that illustrates the use of the Python-API from my point of view. Very soon I will work on the specifics of the Python-API.

Just for the record: we have already a MCF solver in C++ in my repository https://github.com/Lagrang3/mincostflow and we have a prototype of the uncertainty network and payment session already in this repository. We are defining the C and Python APIs before implementation.

Comments are welcomed!