One to N payment system for PFS

[karlb]

Overview

After discussing different options to pay the PFS, the currently favored approach has the following properties

• easy to implement
• low initial gas cost even when fees are paid to many PFSs
• a certain risk of double spends is accepted

The concept is based on the idea to use a user's single deposit in the UDC as a security deposit for off-chain payments to all PFSs.
The client sends an IOU consisting of (sender, receiver, amount, expiration, signature) to the PFS with every path finding request. The PFS verifies the IOU and checks that amount >= prev_amount + pfs_fee. At any time, the PFS can claim the payment by submitting the IOU on-chain. Afterwards, no further IOU with the same (sender, receiver, expiration) can be claimed.

Related:

• https://github.com/raiden-network/team/issues/257
• https://github.com/raiden-network/team/issues/256
• https://gist.github.com/heikoheiko/214dbbd954e0f97e0e13b2fefdc7c753

Requirements

• low latency (<1s)
• reliability, high probability of success (P > 0.99)
• low cost overhead (<5% of transferred amount)
• low fraud rate (< 3%, i.e. some fraud is tolerable)
• can be implemented quickly

Communication between client and PFS

When requesting a route, the IOU is added as five separate arguments to the existing HTTP query params (https://raiden-network-specification.readthedocs.io/en/latest/pathfinding_service.html#arguments):

Field Name	Field Type	Description
sender	address
receiver	address
amount	uint256
expiration_block	uint256	last block in which the IOU can be claimed
signature	bytes	Signature over (`\x19Ethereum Signed Message:\n`, message_length, sender, receiver, amount, expiration_block) signed by sender's private key

The PFS then thoroughly checks the IOU:

• Is the PFS the receiver
• Did the amount increase enough to make the request profitable for the PFS (amount >= prev_amount + pfs_fee)
• Is expiration_block far enough in the future to potentially accumulate a reasonable amount of fees and claim the payment
• Is the IOU for (sender, receiver, expiration) still unclaimed
• Did the client create too many small IOU instead of increasing the value of an existing one? This would make claiming the IOU unprofitable for the PFS
• Is the signature valid
• Is the deposit much larger than amount

If one of the conditions is not met, a corresponding error message is returned and the client can try to submit a request with a proper IOU or try a different PFS. Otherwise, the PFS returns the requested routes as described in the current spec and saves the latest IOU for this (sender, expiration_block).

Claiming the IOU

A OneToN contract (OTNC) which is trusted by the UDC accepts IOUs (see table above for parameters) and uses the UDC to transfer amount from sender to receiver. The OTNC stores a mapping hash(receiver, sender, expiration_block) => expiration_block to make sure that each IOU can only be claimed once.
To make claims more gas efficient, multiple claims can be done in a single transaction and expired claims can be removed from the storage.

Expiration

Having the field expiration_block as part of the IOU serves multiple purposes:

• Combined with the sender and receiver fields it identifies a single payment session. Under this identifier, multiple payments are aggregated by continuously increasing the amount and only a single on-chain transaction is needed to claim the total payment sum. After claiming, the identifier is stored on-chain and used to prevent the receiver from claiming the same payments, again.
• When old IOUs have expired (current_block > expiration_block), the sender can be sure that he won't have to pay this IOU. So after waiting for expiry, the sender knows that IOUs which have been lost for some reason (e.g. disk failure) won't be redeemed and does not have to prepare for unpredictable claims of very old IOUs.
• Entries can be deleted from the hash(receiver, sender, expiration_block) => expiration_block mapping which is used to prevent double claims after expiry. This frees blockchain storage and thereby reduces gas costs.

Double Spending

Since the same deposit is used for payments to multiple parties, it is possible that the deposit is drained before each party has been paid. This is an accepted trade-off, because the amounts are small and low gas costs are more important, as long as the actual double spending does not reach a high level. To somewhat reduce the risks of double spends, the following precautions are taken:

• Users can't immediately withdraw tokens from the UDC. They first have to announce their intention and then wait until a withdraw delay has elapsed.
• The PFS demands a higher deposit than it's currently owed amount to give it some safety margin when other parties claim tokens
• Only PFSs registered in the RSBC are allowed to claim IOUs. This is important because claims allow circumventing the UDC's withdraw delay.

A user and a PFS can theoretically collude to quickly withdraw the complete deposit (via a claim) before other services are paid. This should be unlikely due to the following aspects:

• The savings achieved by cheating the other services are low compared to the coordination cost for the collusion
• The PFS is itself a party receiving payments of services and does not want to promote cheating against services
• If this becomes widespread, cheating users can theoretically be blacklisted by PFSs. This will require them to close their existing channels and reopen new channels at a cost which will most likely be higher than the profit gained by cheating

Specification State

First draft, awaiting comments. I plan to move this into the Raiden spec as soon as the discussion dies down and the comments are worked in.

[karlb]

The spec contains the latest information about the PFS payments. Please refer to https://raiden-network-specification.readthedocs.io/en/latest/service_contracts.html#oneton instead of this ticket.