Messages

Protocol.Messages History

Hide minor edits - Show changes to output

Added line 34:
* protocol version
March 15, 2011, at 11:05 AM by Ryan - relaying to nodes on known hosts
Changed lines 52-55 from:
(node to neighbour in trust network)

For relaying an encrypted message on to a non-neighbouring node, for example, when its host is not
known.
to:
(node to node)

For relaying an encrypted message on to another node.  The only way to pass a message to a node whose host is not known.  Might also be useful for deceiving traffic analyzers by routing through several other nodes when communicating with nodes whose host may be
known.
Added line 57:
  * may be bare address or address@host
Changed line 118 from:
   * allows other nodes to contact this node's host directly, for efficient inquiry.
to:
   * allows other nodes to contact this node's host directly.
March 15, 2011, at 10:59 AM by Ryan - Ordering of shortcut links to match order in text
Added line 18:
* [[#Payment_Init | Payment Init]]
Added line 20:
* [[#Promise | Promise]]
Deleted lines 22-23:
* [[#Payment_Init | Payment Init]]
* [[#Promise | Promise]]
March 15, 2011, at 10:57 AM by Ryan - Removed credit reservation fee; added status query and single-node credit check; relayed messages
Changed lines 5-20 from:
Messages to a particular node are sent directly to that node's host, not relayed across the trust network.


*[[#Header_for_all_messages|Header for all messages]]

*[[#Credit_Offer|Credit Offer]]
*[[#Credit_Accept|Credit Accept]]
*[[#Credit_Check|Credit_Check]]
*[[#Payment_Accept|Payment Accept]]
*[[#Commit_Ready|Commit Ready]]
*[[#Promise_Release|Promise Release]]
*[[#Payment_Init|Payment Init]]
*[[#Promise|Promise]]
*[[#Commit|Commit]]
*[[#IOU|IOU]]
to:
Messages to a particular node may be sent directly to that node's host if it is known, or encrypted and relayed across the trust network.


* [[#Header_for_all_messages|Header for all messages]]

* [[#Relay | Relay]]

* [[#Credit_Offer | Credit Offer]]
* [[#Credit_Accept | Credit Accept]]
* [[#Credit | Credit]]
* [[#Exchange_Rate| Exchange Rate]]
* [[#Credit_Check | Credit_Check]]

* [[#Payment_Accept | Payment Accept]]
* [[#Commit_Ready | Commit Ready]]
* [[#Promise_Release | Promise Release]]
* [[#Payment_Init | Payment Init]]
* [[#Promise | Promise]]
* [[#Commit | Commit]]
* [[#IOU | IOU]]
* [[#Status_Query | Status Query]]
* [[#Status | Status
]]
Changed lines 29-32 from:
[[<<]]


to:

Added lines 48-60:

[[#Relay]]
!! Relay

(node to neighbour in trust network)

For relaying an encrypted message on to a non-neighbouring node, for example, when its host is not known.

* destination node
* encrypted message (including header)
  * may be another relay message containing another encrypted message, allowing onion routing, obscuring the ultimate destination.

Added lines 68-69:
May also be used to inform an existing partner when a node has changed hosts: it can glean the new host from the 'from' address in the header.
Changed lines 76-77 from:
* list of acceptable commit message arbiters (optional)
  * should probably include their URLs and signing keys.
to:
* list of acceptable commit message arbiter public keys (optional)
  * more info on arbiter keys in [[#Promise | promise message]] below
Added line 82:
Changed line 92 from:
* list of acceptable commit message arbiters (optional)
to:
* list of acceptable commit message arbiter keys (optional)
Changed lines 94-95 from:
* proof if owner identity (optional)
to:
* proof of owner identity (optional)


[[#Credit]]
Changed line 110 from:
     * may be number or URL
to:
     * may be number or reference to broadcast exchange rate ID (see below)
Changed lines 112-118 from:
  * sequence number
   * only rule is increase this every message, so we know which is newer when comparing
 
  * wrap around at 2^31
     * rule: numbers under 1 billion are considered higher/newer than numbers over 2 billion when comparing
  * credit reservation fee
    * as percentage of credit reserved, per unit time until expiry of reservation
    * valid until
to:
      * maybe allow node to indicate that it uses a common broadcast exchange rate, but modified by a fixed amount?
       * eg, [rate ID] + 1%
  * flat fee on through transactions, in node base units
Changed lines 116-132 from:
to:
  * node hostname (+ port) (optional)
    * allows other nodes to contact this node's host directly, for efficient inquiry.


[[#Exchange_Rate]]
!! Exchange Rate

(broadcast)

Exchange rate advertisement.  Allows frequent updates for common exchange rates that may be used by multiple nodes on multiple hosts across the network.  Using common exchange rates means less update traffic.

* rate ID
  * public key which signs the rate update messages
* numeric exchange rate (multiplier for unit conversion)
* valid until

Changed lines 136-139 from:
(potential payer to recipient, and then back through flow network)

For getting up-to-date credit availability and fee information before initiating
payment.
to:
(potential payer to recipient, and then back through flow network; or just payer to any intermediary with response directly back)

For getting up-to-date credit availability and fee information before initiating
payment, either from an entire payment flow network, or from a single node.
Added line 149:
Added line 177:
Deleted lines 188-189:
* credit reservation fee
  * this message acts as an IOU forward for credit reservation fee
Deleted line 198:
  * credit reservation fee at each edge
Added line 202:
Added line 220:
Added line 232:
Added lines 245-271:
[[#Status_Query]]
!! Status Query

(payer to any intermediary or recipient)

Requests information about the current state of the transaction as seen by another participant.

* transaction ID
* signed by payer commit key

[[#Status]]
!! Status

(intermediary or recipient to payer)

Response to status query.

* transaction ID
* one or more status values:
  * unknown transaction ID
  * waiting for promise (only received some promises of expected promises to be merged)
  * promise received
  * promise rejected
  * promise released
  * promise expired
  * commit received
  * IOU received (is this any of the payer's business?)
March 04, 2011, at 06:24 PM by Romualdo Grillo -
Changed line 7 from:
!! Message types list:
to:
Added line 9:
March 04, 2011, at 03:07 PM by Romualdo Grillo -
Added lines 7-25:
!! Message types list:
*[[#Header_for_all_messages|Header for all messages]]
*[[#Credit_Offer|Credit Offer]]
*[[#Credit_Accept|Credit Accept]]
*[[#Credit_Check|Credit_Check]]
*[[#Payment_Accept|Payment Accept]]
*[[#Commit_Ready|Commit Ready]]
*[[#Promise_Release|Promise Release]]
*[[#Payment_Init|Payment Init]]
*[[#Promise|Promise]]
*[[#Commit|Commit]]
*[[#IOU|IOU]]

[[<<]]
[[<<]]



[[#Header_for_all_messages]]
Added line 42:
[[#Credit_Offer]]
Added line 61:
[[#Credit_Accept]]
Added line 97:
[[#Credit_Check]]
Added line 113:
[[#Payment_Init]]
Added lines 126-127:

[[#Payment_Accept]]
Added line 140:
[[#Promise]]
Added line 167:
[[#Commit_Ready]]
Changed line 175 from:
to:
[[#Promise_Release]]
Added line 184:
[[#Commit]]
Added line 195:
[[#IOU]]
March 02, 2011, at 08:43 PM by Ryan - added descriptions, way to init account (link LoC's, agree on unit), etc.
Changed lines 1-58 from:
Credit (broadcast)
to:
Messages (including header) are signed by the sender's node key.

A requirement is that these messages can be used after the fact to prove a node's actions, in case there is a disagreement.

Messages to a particular node are sent directly to that node's host, not relayed across the trust network.

!! Header for all messages

* message type
* to (optional)
  * eg, 1BteW1uy7zNXMNqhFdvFafbJLd1HcHVPLx, or 1BteW1uy7zNXMNqhFdvFafbJLd1HcHVPLx@ripplepay.com
* to_alias (optional)
  * used instead of 'to' when correct node address is not known
  * eg, ryan@ripplepay.com
* from
* from_key
  * full key for validating message signature
* from_alias (optional)
  * for responses to messages with 'to_alias', 'from' provides actual node address, 'from_alias' references the value of 'to_alias' that received the original message
  * note that a server can use an alias to refer to more than one actual node address, depending on who's asking
* time (UTC)

!! Credit Offer

(account initiator to potential partner)

For initializing a line of credit, which is one direction/half of a mutual credit account between two nodes.  Used to specify node addresses for aliases, units, arbiters for who is responsible for stalled commit messages, proving node owner identity, and linking two lines of credit together into a mutual credit account.

Credit amounts are determined later, with credit advertisements.

* line of credit (LoC) ID
* linked LoC ID (optional)
  * allows two lines of credit in opposite directions to have a linked balance and form a mutual credit account (lines of credit need not be between same node addresses)
* units
* list of acceptable commit message arbiters (optional)
  * should probably include their URLs and signing keys.
* note (optional)
* proof of owner identity (optional)
  * eg, PGP signature

!! Credit Accept

(partner to account initiator)

* LoC ID
* linked LoC ID (optional)
* credit amount accepted
* units
* list of acceptable commit message arbiters (optional)
* note (optional)
* proof if owner identity (optional)

!! Credit

(broadcast)

Routing advertisements.  Can be bundled together for transmission.

Changed line 62 from:
   * account ID
to:
   * LoC ID
Changed lines 76-78 from:
Credit Check (potential payer to recipient, and then back through flow network)
* routing (optional)
  * allows recipient to request most recent credit information for a flow network he is interested
in.
to:
!! Credit Check

(potential payer to recipient, and then back through flow network)

For getting up-to-date credit availability and fee information before initiating payment.

* routing
  * allows payer to request most recent credit information for a flow network he is interested
in using.
Changed lines 91-98 from:
Payment Init (payer to recipient)
to:
!! Payment Init

(payer to recipient)

Inform recipient of an intended payment.  This message gets signed by recipient and passed right back. 

Units are not included, since they don't add anything to proving a payment of a certain amount was made.  For example, a seller says "pay 30 to node X".  The payer will be able to prove she did that.  If the seller says "pay 30 CAD to node X", the payer won't be able to prove anything about node X's valuation or use of CAD, so the units are meaningless to the protocol (but might be useful for the payer to know about how much she will have to send out).

Changed lines 102-105 from:
* potential problem: need units somewhere to prove to a third party how much was paid?
  * maybe not: the amount is the important thing -- recipient offered trade for certain amount delivered to node; payer can prove amount was delivered; the rest is out of scope

Payment Accept (recipient to payer)
to:

!! Payment Accept

(recipient to payer)

Gives payer a recipient-signed copy of payment amount tied to transaction ID, which, combined with signed commit message, proves payment occurred.

Changed lines 111-112 from:

Promise (from payer, forward through flow network)
to:
* proof of recipient node owner identity (optional)
* commit message URL (optional)
  * location commit message will be publicly available when it is ready

!! Promise

(from payer, forward through flow network)

A promise to pass forward IOUs when shown a commit message signed by the payer and recipient commit keys before the expiry datetime (or when shown a commit message timestamped before the expiry by an acceptable arbiter).  Acts as a credit reservation.

Changed line 122 from:
* account ID
to:
* LoC ID
Changed lines 129-133 from:
* list of:
  * commit message arbiter URL
 
  * location that promisee can post commit message if promisor is unreachable and have it timestamped as proof of commit before expiry
  * if all arbiter URLs are unacceptable, promise should be rejected with promise_release
 
* might want a way for neighbours to negotiate this ahead of time?
to:
* commit message URL
* list of acceptable commit message arbiter keys
  * if at any time a commit message is presented signed by any of these keys, and timestamped before promise expiry, the promisor must pass IOUs forward as per promise
 
* presumably the arbiter will publish these somewhere the promisor knows where to find them.
  * if all arbiter keys are unacceptable, promise should be rejected with promise_release
Changed lines 141-146 from:
Commit Ready (recipient to payer, having received sufficient promises)
to:
!! Commit Ready

(recipient to payer)

The recipient has
received sufficient promises and is ready to commit the transaction.
Changed lines 149-154 from:
Promise Release (recipient or intermediary to predecessor)
to:
!! Promise Release

(recipient or intermediary to predecessor)

Release promisor from its promise.

Changed lines 157-162 from:
Commit (from recipient, back through flow network; also broadcast)
to:
!! Commit

(from recipient, back through flow network; also broadcast)

Trigger promises.

Changed lines 167-168 from:
Commit Acknowledge (payer or intermediary to successor)
* transaction ID
to:
!! IOU

(payer or intermediary to successor)

Affirms that IOUs were issued.  May be used outside a transaction in order to simply pass IOUs to an account partner (an act that needs no permission, fees, or available credit).

* transaction ID (optional)
Changed lines 175-176 from:
  * account ID
  * amount committed on account
to:
  * LoC ID
  * amount committed on LoC
 
Added lines 1-76:
Credit (broadcast)
* source node(s)
  * list of offers and accepts to and from other nodes
    * partner node
    * account ID
    * amount
    * exchange rate to/from node base unit
      * may be number or URL
      * valid until (number only)
  * sequence number
    * only rule is increase this every message, so we know which is newer when comparing
    * wrap around at 2^31
      * rule: numbers under 1 billion are considered higher/newer than numbers over 2 billion when comparing
  * credit reservation fee
    * as percentage of credit reserved, per unit time until expiry of reservation
    * valid until
  * requested hop limit for privacy? (optional)

Credit Check (potential payer to recipient, and then back through flow network)
* routing (optional)
  * allows recipient to request most recent credit information for a flow network he is interested in.
  * onion-routed flow network
    * set of edges, with paths forking and merging
  * key to encrypt each node's response
* list of node responses, in order
  * each is a credit message body, encrypted with the checker's key
  * may be padded with bogus responses at the start to disguise true number of intermediaries

Payment Init (payer to recipient)
* transaction ID
* amount (to be received at recipient node, in node base units)
* memo
* potential problem: need units somewhere to prove to a third party how much was paid?
  * maybe not: the amount is the important thing -- recipient offered trade for certain amount delivered to node; payer can prove amount was delivered; the rest is out of scope

Payment Accept (recipient to payer)
* copy of payment_init message
* recipient commit key

Promise (from payer, forward through flow network)
* transaction ID
* account ID
* amount to go forward
* expiry datetime
* credit reservation fee
  * this message acts as an IOU forward for credit reservation fee
* payer commit key
* recipient commit key
* list of:
  * commit message arbiter URL
    * location that promisee can post commit message if promisor is unreachable and have it timestamped as proof of commit before expiry
  * if all arbiter URLs are unacceptable, promise should be rejected with promise_release
  * might want a way for neighbours to negotiate this ahead of time?
* routing onion
  * flow network: sets of edges, with paths forking and merging
  * amount to go forward at each edge
  * credit reservation fee at each edge
  * exchange rate at each edge/node
  * nodes where merging happens should know to expect it so they can wait for it and perform merge before forwarding promise

Commit Ready (recipient to payer, having received sufficient promises)
* transaction ID

Promise Release (recipient or intermediary to predecessor)
* transaction ID

Commit (from recipient, back through flow network; also broadcast)
* transaction ID
* payer commit signature
* recipient commit signature

Commit Acknowledge (payer or intermediary to successor)
* transaction ID
* list of:
  * account ID
  * amount committed on account