You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow a Raiden payment to be used as part of a larger process were the payment is a step that should succeed based on external dependencies and conditions.
One example of such process is atomic swap of ERC20 and Bitcoin. In such process the ERC20 payment should succeed if and only if a Bitcoin payment succeeded. A practical use case is described here https://hackmd.io/s/SyZOK0OfN?
In order to provide this functionality Raiden should allow the secret and the secretHash to be provided by the payer or the payee and should allow the payer to know the secret once the payment was done.
This feature allows the payer to optionally provide a secret_hash that should be used for the payment
Allow the API caller to include a secret_hash as part of the payment request
POST /api/v1/payments/0x2a65Aca4D5fC5B5C859090a6c34d164135398226/0x61C808D82A3Ac53231750daDc13c777b59310bD9 HTTP/1.1
If no secret_hash provided as part of the payment request the secret and the hash should be selected by the Raiden server as today.
If a secret_hash was provided, raiden should not create a secret but use the provided secret_hash as part of the locked payment message.
It is assumed that the payee will be able to find the secret for the secret_hash without asking the initiator to reveal the secret. If secret request arrives from the target and the secret is unknown (since only the secret_hash provided by the payer), raiden should execute as it is doing today if/when it gets a secret request and the secret_hash provided is unknown.
Feature is backward compatible as it is a new functionality that does not impact the way Raiden is working today.
The text was updated successfully, but these errors were encountered: