Ledger loops split

[michielbdejong]

Hubbie+Ledger part is working, unconditional transfers get adminstered correctly in the in-browser demo, and it's sending probes around now.

Next step to fix: it now detects loop when it notices a repeat-send in the same direction; should already detect one if the same routeId comes in from different directions, maybe? Or is this setup enough?

[michielbdejong]

This is all still harder than it seemed...

• If you have the console open, the balances get out of sync and everybody ends up thinking they have 40 UCR in the bank :(
• If you don't have the console open, 32 UCR stays in an unresolved loop
• REJECTs get repeated and lead to unknown-reject errors
• if you increase the amount from balanceDiff / 10 to balanceDiff / 2, everybody proposes a loop, and everybody rejects the two other players' loops, after which no new loops get proposed.

Should I add randomized retry delays to avoid deadlocks like that? Maybe bandwidth should be divided between the number of candidate loops, that would be a first step.

Am I wasting time on the current simple routing scheme? Some of these issues will be different when I introduce probe replies.

[michielbdejong]

what happens if your peer sends both a FULFILL and a REJECT? the second message should be ignored. Would be good to have unit tests for the Ledger layer to ensure this. That's where the split between Ledger and Loops should offer benefit, so actually it's a nice opportunity that I now have a real examples where ledgers get out of sync :)

[michielbdejong]

There are still some issues with the current code, but I'll resolve those in follow-up PRs:

• the ledger should be more like a message log, grouped by msgId. that will make it easier to repeat responses (including when that response was a REJECT)
• user-level ledger
• recover from data loss
• a lot of work can still be done on the loops engine.