🎀Transaction Processing

Once a service requester receives both the bid response and unchoke messages, it opens a payment channel on the private ledger whose output is addressed to the service provider. The service provider expects payment to be delivered via a new or existing channel for each complete piece received by the service requester.

Below, the service requester is the party sending TOS, and the service provider is the party receiving it.

1. The service requester creates a public key (K1) and requests a public key from the service provider (K2).

2. When the service requester wishes to pay the service provider, it opens a channel on the private ledger with K2 as the destination account. When the channel is created, the service requester transfers some of its TOS into the channel. This TOS is deducted from the account associated with K1.

3. The service requester generates a transaction on the channel which disburses the initial payment amount to K2 and the remainder of the channel’s TOS to K1.

4. The service requester signs the transaction, then sends the transaction and the signature to the service provider.

5. If the service provider has not seen the channel before, it requests the channel information from the private ledger. The service provider only accepts the payment if the channel information retrieved from the ledger matches the information received from the service requester.

6. When the service requester wishes to send another payment to the service provider, it adjusts the transaction to allocate more value to K2. It then re-signs the new transaction and sends the transaction and the signature to the service provider.

7. If the service requester wishes to send more payment, but the existing channel’s TOS is entirely allocated to the service provider, the service requester opens a new channel on the ledger and uses it to send payment as described in steps 2-4.

This process continues until the service requester confirms that the transfer is complete. The service provider then signs the last transaction it saw and sends it to the private ledger, allocating the final amount to itself. This closes the channel; it cannot be used for further payments.

In case the service provider stops at any point, leaving the allocated value in limbo, the private ledger implements a timeout for each channel. The timeout period is indicated in the channel’s information when the service provider retrieves it from the ledger. If the service provider does not close the channel before the timeout expires, the ledger automatically closes the channel and disperses all of the channel’s TOS token to the service requester.

If the TOS transfer does not complete after a timeout, the service requester is choked and receives no further data. Repeated failures to transfer TOS by a service requester can result in the service provider banning the service requester. Banned service requesters are disconnected from service providers, and any attempt to reconnect is rejected for a specified period of time. Similarly, failure to verify data from the service provider can result in the service provider being banned.

Each party progressively contributes pieces or TOS token, with a signed transaction produced for each step in the process. The maximum breach exposure of the service provider at any given time is therefore one piece worth of bandwidth; since service requesters pay only on verified delivery, they have zero breach exposure.