Protocol /
PathDiscoveryWorkPage
Protocol.PathDiscoveryWorkPage History
Hide minor edits - Show changes to output
Changed lines 14-15 from:
to:
* no response means no action required other than collect the penalty after the deadline if no receipt shows up (done by payment request)
Changed lines 9-14 from:
* also have fee-limits and other usual query-routing stuff, incl. routing onion
* 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 (done by payment request)
* how many path units from each path are in the final payment is decided by the payer when issuing receipts
* Instead of path_responses, recipient/intermediaries send back full or partial promise releases to indicate lack of
* no response means no action required other than collect the penalty after the deadline (done by payment request)
* how many path units
to:
* 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
* 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
Changed lines 3-4 from:
* Recipient issues path_available messages (like queries - optional)
to:
* Recipient issues path_available messages (essentially path_queries)
* optional - only if payer has revealed its routing ID
* optional - only if payer has revealed its routing ID
Added line 7:
* may wait until path_availables are received, if only payer has revealed its routing ID
Added lines 12-14:
* how many path 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.
* recipient reports actual value of each path in payment units when reporting promises received.
Added lines 1-16:
'''New Path-Discovery/Transaction Mechanism'''
* Recipient issues path_available messages (like queries - optional)
* Payer issues promises right off (no queries)
* promises have time-to-penalty and final deadline as usual
* also have fee-limits and other usual query-routing stuff, incl. routing onion
* 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 (done by payment request)
* 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
-------------------------
* Recipient issues path_available messages (like queries - optional)
* Payer issues promises right off (no queries)
* promises have time-to-penalty and final deadline as usual
* also have fee-limits and other usual query-routing stuff, incl. routing onion
* 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 (done by payment request)
* 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
-------------------------
Deleted lines 68-69:
-------------------------
Added line 4:
Changed line 18 from:
* time to penalty deadlin
to:
* time to penalty deadline
Added lines 24-28:
* 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???
* 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???
Added line 30:
Added line 33:
Added lines 37-53:
* 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)
* 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)
Changed lines 26-28 from:
to:
* Forking:
* alternative forking formula: minimize [sum over all forks(query amount * distance to target)] * # of forks
* alternative forking formula: minimize [sum over all forks(query amount * distance to target)] * # of forks
Changed line 12 from:
* store in onion:
to:
* required for onion layers encoded for a node other than oneself:
Changed lines 21-22 from:
* node may store anything for itself, but an onion layer created by a third party must be standardized
to:
* 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
* a node may wish to store not only data for next promise hop, but also to confirm data received on previous promise hop
Added line 6:
* allows third party to compose a path using alternative path discovery methods
Added lines 8-11:
* onion layer wrapper contains:
* encryption method
* key reference (public key fingerprint)
* key size
* encryption method
* key reference (public key fingerprint)
* key size
Added line 20:
* node may store anything for itself, but an onion layer created by a third party must be standardized
Changed lines 7-14 from:
* the conversion rate between transaction and account units for the next hop
* time to final receipt deadline
to:
* store in onion:
* next hop node ID
* next hop units
* the conversion rate between transaction and account units for the next hop
* time to penalty deadlin
* late-receipt penalty rate
* time to final receipt deadline
* path best-before date
* next hop node ID
* next hop units
* the conversion rate between transaction and account units for the next hop
* time to penalty deadlin
* late-receipt penalty rate
* time to final receipt deadline
* path best-before date
Changed lines 7-14 from:
* next hop units
* the conversion rate between transaction and account units for the next hop
* time to penalty deadlin
* late-receipt penalty rate
* time to final receipt deadline
to:
* store in onion:
* next hop node ID
* next hop units
* the conversion rate between transaction and account units for the next hop
* time to penalty deadlin
* late-receipt penalty rate
* time to final receipt deadline
* path best-before date
* path best-before date
* next hop node ID
* next hop units
* the conversion rate between transaction and account units for the next hop
* time to penalty deadlin
* late-receipt penalty rate
* time to final receipt deadline
* path best-before date
* path best-before date
Changed lines 4-16 from:
to:
* onion routing
* store state between path-search and payment phase in a routing onion instead of locally at each node
* build on path-query phase (from recipient to payer), and then use on promise phase
* store in onion:
* next hop node ID
* next hop units
* the conversion rate between transaction and account units for the next hop
* time to penalty deadlin
* late-receipt penalty rate
* time to final receipt deadline
* 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
* store state between path-search and payment phase in a routing onion instead of locally at each node
* build on path-query phase (from recipient to payer), and then use on promise phase
* store in onion:
* next hop node ID
* next hop units
* the conversion rate between transaction and account units for the next hop
* time to penalty deadlin
* late-receipt penalty rate
* time to final receipt deadline
* 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
Deleted lines 17-20:
'''Path Queries & Responses'''
Build a routing onion to make the path discovery method more independent of the Payment Transaction phase.
Added lines 1-6:
'''To Do'''
* express time limit in real time instead of/in addition to hops?
-------------------------
* express time limit in real time instead of/in addition to hops?
-------------------------
Added lines 1-3:
'''Path Queries & Responses'''
Build a routing onion to make the path discovery method more independent of the Payment Transaction phase.
Build a routing onion to make the path discovery method more independent of the Payment Transaction phase.