New Path-Discovery/Transaction Mechanism
- Recipient issues path_available messages (essentially path_queries)
- optional - only if payer has revealed its routing ID
- Payer issues promises right off (no queries)
- may wait until path_availables are received, if only payer has revealed its routing ID
- promises have time-to-penalty and final deadline as usual
- also have fee-limits and other usual query-routing stuff
- Promises are routed like queries (targetted depth-first search)
- guided by routing onion, if available from either path_available phase or advertisements
- instead of path_responses, recipient/intermediaries send back full or partial promise releases to indicate lack of available credit
- no response means no action required other than collect the penalty after the deadline if no receipt shows up (done by payment request)
- How many path units (old name: transaction units) from each path are in the final payment is decided by the payer when issuing receipts
- recipient reports actual value of each path in payment units when reporting promises received.
- When promises reach recipient, finalizing the transaction proceeds normally.
- important that the recipient doesn't send promise-bundle to payer until it's all there to avoid a situation where the recipient bails out just as the payer sends receipts
To Do
- express time limit in real time instead of/in addition to hops?
- onion routing
- store state between path-search and payment phase in a routing onion instead of locally at each node
- allows third party to compose a path using alternative path discovery methods
- build on path-query phase (from recipient to payer), and then use on promise phase
- onion layer wrapper contains:
- encryption method
- key reference (public key fingerprint)
- key size
- required for onion layers encoded for a node other than oneself:
- next hop node ID
- next hop units
- next hop account ID
- the conversion rate between transaction and account units for the next hop
- time to penalty deadline
- late-receipt penalty rate
- time to final receipt deadline
- path best-before date
- a node may store anything for itself, but an onion layer created by a third party must be standardized
- a node may wish to store not only data for next promise hop, but also to confirm data received on previous promise hop
- onion routing from ads
- no credit guarantee - must gracefully handle expired paths
- easiest way may be to allow an onion in path queries
- otherwise, maybe allow reversion to path discovery mid-transaction???
- path best-before date
- flag indicating whether to freeze credit during path-query (not freezing may be useful in credit checks)?
- payer would need to pass this to recipient during Initialization phase as well
- Forking:
- alternative forking formula: minimize [sum over all forks(query amount * distance to target)] * # of forks
- once target is reached, queries must be returned so that intermediaries learn about the final path IDs and amounts
- can be used to give precise amounts to forward queries!
- recipient must inform payer of queries received and their amounts
- screws up path amount/units because payer may send query with exact amount in path units, but it reaches recipient as another amount!
- maybe exclude path_amount & path_units from forward queries?
- once payer receives return values for amounts in account units, it can decide to search further if necessary
- routing queries with no target or where the target is an intermediary
- when forking, append a new entry to a path-ID list, so that a query's path-ID forking history is self-contained
- avoids need for list of aliases to avoid looping!
- avoids need for nodes to recall which path ID forked from which path ID -- only need to store which neighbour sent query for which path ID
- when returning, can remove path-ID layers that you created, and return back original path ID with aggregate fork amounts, etc.
- once payer (or recipient?) receives queries totaling the payment amount from a single search, can immediately begin promise phase without waiting for queries to fully return! (Since the only thing preventing this was intermediaries not knowing what the final path IDs referred to in their context.)
- limiting query propagation using max-fee field (backward) or path_amount (forward)