fast all-or-nothing cycle resolution

[michielbdejong]

if cycle resolution is fast and all-or-nothing, it can be used for payment use cases, such as paying for a coffee on the spot.

there are three ways to pay for a coffee:

• the cafe trusts you for the amount of the coffee, and also trusts the network to eventually find a loop. you only have to write it down (maybe they'll check your identity)
• you trust the cafe, and first already created a ledger with them, and set it to fill up some balance from network money. annoying thing is that this requires preparation.
• the network is so fast that you can pay & get settled while-you-wait, within a number of seconds

for the third option, maybe the cafe can send you a WAYMARKS message with 'near' users. after that,. you can send out a probe mentioning those waymarks. there is a network topology assumption here:

suppose a core set of network nodes form a fully connected backbone, and every user is connected directly with one of these core nodes. The core node have no privacy considerations about their own identity being broadcast, and it also does not imply any sensitive information to say which core node(s) you are connected to yourself.

Alice wants to pay Bob. Alice starts a probe, fwise to Bob and cwise to her own core node W1. In the probe messages to Bob she includes the string 'W1' as a waymark. Bob forwards the probe to his own core node W2, including the W1 waymark. W2 recognizes the waymark and forwards the fwise probe to W1 only, who does not forward it further, and there the loop is started.

1 Alice -> Bob: fwise(W1) | Alice -> W1 COND 2 Bob -> W2: fwise(W1) 3 W2 -> W1: fwise 4 W1 -> W2: COND 5 W2 -> Bob: COND 6 Bob -> Alice: COND

7 Alice -> Bob: ACCEPT(COND), ADD 8 Bob -> Alice: ACCEPT(ADD) | Bob -> W2 ACCEPT(COND) 9 W2 -> W1: ACCEPT(COND) 10 W1 -> Alice: ACCEPT(COND)

same, with Alice and Bob both multi-homing:

1 Alice -> Bob: fwise(W1,W2) | Alice -> W1 COND1 | Alice -> W2 COND2 2 Bob -> W3: fwise(W1,W2) | Bob -> W4: fwise(W1,W2) 3 W3 -> W1: fwise | W4 -> W1: fwise | W3 -> W2: fwise | W4 -> W2: fwise 4 W1 -> W3: COND1 | W2 -> W4: COND2 5 W3 -> Bob: COND1 | W4 -> Bob: COND2 6 Bob -> Alice: COND1, COND2

7 Alice -> Bob: ACCEPT(COND1), ADD 8 Bob -> Alice: ACCEPT(ADD) | Bob -> W3 ACCEPT(COND1) 9 W3 -> W1: ACCEPT(COND1) 10 W1 -> Alice: ACCEPT(COND1)

[michielbdejong]

this requires:

• a way to add one or more waymark strings to a probe
• a way for core nodes to tell each other what their public names for use as waymarks are
• a way to mark neighbors as upstream? or should Bob send Alice's probe to all his customers?
• give named neighbors preference when forwarding waymarked probes

[michielbdejong]

actually, that's a funny thought - if Alice's friends have credit behind the bar at the cafe, and they are online, then Alice could also send one of her own identities. the cafe can then not be accused of being a payment provider, since they are themselves the payee! also, Alice's friends are definitely not offering a payment service since they are not the one in the hub role - the cafe is both payee and hub.

[michielbdejong]

i should label this as the 'unicurn' sub-project, where Hubbie, SNAP and LedgerLoops are used to implement all-or-nothing payments.

The 'Network Money' app should support both LedgerLoops (marking ledgers as 'use as network money' or 'fill with network money') and Unicurn (instead of creating a ledger entry to a user, attempt to make a Unicurn payment to them).