Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inject a hash with payment request (API) #3318

Closed
offerm opened this issue Jan 24, 2019 · 0 comments · Fixed by #3447
Closed

Inject a hash with payment request (API) #3318

offerm opened this issue Jan 24, 2019 · 0 comments · Fixed by #3447

Comments

@offerm
Copy link
Contributor

offerm commented Jan 24, 2019

Abstract & Motivation

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

Specification

Allow the API caller to include a secret_hash as part of the payment request

POST /api/v1/payments/0x2a65Aca4D5fC5B5C859090a6c34d164135398226/0x61C808D82A3Ac53231750daDc13c777b59310bD9 HTTP/1.1
Host: localhost:5001
Content-Type: application/json

{
"amount": 200,
"identifier": 42,
"secret_hash": "0x97caeb8aa1c0080da340c179a6acb859abdfd045cab2b96d46589260957adffe",
}

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.

Backwards Compatibility

Feature is backward compatible as it is a new functionality that does not impact the way Raiden is working today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant