Recent Changes - Search:
Protocol /

PaymentTransactionWorkPage

Risk-reducing ideas

  • Allow intermediaries to specify max-receipt: the max amount of the payment they wish to handle at one time (ie, risk being stuck with)
    • requires partial receipts => over-promises must be cleared by combination of receipt(s) and promise-release(s)
    • requires next_receipt message once intermediary has relayed receipt and is ready for another
      • should contain max amount for next receipt - as confidence in path builds, this may grow over time, percolating from payer end back to recipient end??? (Or is this more about the relationship between hosts, and having it change between payments is good enough?)
  • Allow two hosts to agree on one or more 3rd-party referee hosts that will accept, sign, timestamp, attempt to deliver, and make available (via HTTP) a copy of any message that was not properly acknowledged and is time-sensitive. Then responsibility for a downed connection can most likely be made clear.

Evgeni:

Transaction committing module

Transactions in Ripple are committed in two phases:

1. Promise-propagation phase. During this phase a circular chain of conditional promises is built.

1 ----> 2 -----> 3 -----> .... -----> N ----> 1 (----> marks a promise message)

Node 1 is supervisor (or initiator) of the transaction. The supervisor makes the first promise down the chain thus defining the cryptographic condition for all following promises. Supervisor should also include advices for next nodes concerning what promises they have to make in order appropriate payment chain to be built. Promise phase ends when the last node in the chain (N) have made her conditional promise to 'supervisor''.

2. Receipt-propagation phase. During this phase all promise-conditions are triggered.

1 <---- 2 <----- 3 <----- .... <----- N <---- 1 (<---- marks a receipt message)

The supervisor can trigger the execution of promises down the chain by issuing receipt mesage and sending it to node (N). Node (N) retransmits the receipt to node (N-1) and so on and so forth.

...

Practical scenarios:

- Buyer and seller scenario. Buyer is supervisor of the transaction. Seller makes her promises to buyer either in units of the purchase or in widely recognized units (USD, EUR)

- Payer and recepient scenario. ... to be defined

- Circular debt clearing scenario. ... to be defined

...

Making Promises (Commit-Request)

When the payer has found payment paths with enough combined available credit to complete the payment, it sends a promise message to the first node on each path, representing its commitment to redeem a valid receipt that can be authenticated with the promise's authentication key up to the amount of credit indicated on the receipt, if presented before the stated deadline. A promise renews the credit held for each path and gives a new deadline for the expiry of these holds. 

    * URL specifying account units
    * conversion rate between transaction units and account units
    * amount to be held for payment, in transaction units
    * promise penalty deadline
    * daily penalty rate if receipt or path-cancel not received before the penalty deadline
    * promise final deadline, after which promise expires
    * cryptographic nonce to check the receipt against
    * the payer's receipt authentication key for this payment path
    * the recipient's receipt authentication key for this payment path (optional)
    * a timestamp to indicate the time the promise came into effect
    * onion routing blob wich contains an advice describing how to handle the payment further.

Each node passes the promise message on to the next node in the path, as determined by onion routing blob received in the promise message (peeling the onion). At each step, the promise message is signed to the next node by the passing node's authentication key. This serves to establish the integrity and non-repudiability of the promise.

The penalty deadline is the time after which the promising node may begin charging a penalty to its partner for having to hold credit it could be using for payment. The penalty is charged continuously at the daily rate specified. Intermediaries should always set a shorter deadline and higher penalty rate on promises out than they have received on promises in, to ensure that they are compensated for overdue receipts. This provides incentive for the recipient to ensure quick completion or cancellation of each promise path, without requiring hard-and-fast deadlines to come into play so soon that minor delays spawn major disputes.

Finalizing the Payment

The recipient sends the payer promise message, indicating that a corresponding promise has been received: 

    * URL specifying account units (MIGHT be equal to transaction units' URL)
    * conversion rate between transaction units and account units
    * amount to be held for payment, in transaction units
    * promise penalty deadline (SHOULD be equeal to promise final deadline)
    * daily penalty rate if receipt or path-cancel not received before the penalty deadline (SHOULD be zero)
    * promise final deadline, after which promise expires
    * cryptographic nonce to check the receipt against
    * the payer's receipt authentication key for this payment path
    * the recipient's receipt authentication key for this payment path (MUST be missing)
    * a timestamp to indicate the time the promise came into effect (SHOULD be indicating current time)
    * onion routing blob wich contains an advice describing how to handle the payment further. (SHOULD be empty)

The payer can cancel the transaction by releasing the recipient from promises and sending recipient a payment-cancel, informing it that it can release its neighbours from their promises. Released promises should be propagated back down each payment path to free up those funds for other payments.

When the payer receives promise messages equal to or exceeding the amount of the payment, he generates receipt messages matching the promises received by the recipient, authenticates them individually with each promise authentication key, and sends them each to the recipient: 

    * universally unique ID of the receipt
    * amount for this receipt in transaction units 
    * promise's cryptographic nonce

The collection of receipts signed by the payer represents the value of the payment, and once they are given to the recipient, the recipient is considered to have been paid. If any of the receipts does not match its promise (eg, one of the amounts is wrong) or is otherwise invalid (to be rigorously defined), the amount of that receipt is not considered to have been paid until a valid receipt is issued. The recipient must reply with an error code when receiving an invalid receipt.