search

ExchangeUnion / raiden

Raiden Network
https://developer.raiden.network
MIT License
0 stars 0 forks source link

Resume Raiden swap with preimage push/pull #12

Closed kilrau closed 5 years ago

kilrau commented 5 years ago

Enhancement of https://github.com/ExchangeUnion/xud/pull/1081:

When xud crashes between SwapCreated and SwapCompleted: we currently can't attempt to resume swaps with raiden since there is currently no way to "push" a preimage to raiden so that it can settle a payment.

This issue is about adding this functionality, e.g. as a raiden endpoint and subsequently enhance ExchangeUnion/xud#1081 to utilize it.

kilrau commented 5 years ago

Idea from the call: at the moment raiden re-queries the preimage on restart from the resolver. We make it continuously query the preimage from xud.

Question: Can we also tell raiden to cancel(refund) the payment? This would solve https://github.com/ExchangeUnion/xud/issues/1123 . Current behaviour is that payments without preimage get refunded after locktime, which is 20660 blocks - too long.

offerm commented 5 years ago

Refund is a different issue. The resolver can provide the secret or claim that it doesn't have it.

So the plan is: a. if no resolver is configured - use normal raiden flow (target should ask initiator for the secret) b. if resolver is configured - try to resolve: b.i - if you got the secret - continue with the raiden flow - send the secret back to get the mediator/initiator. b.ii- if you got a response that the resolver does not have the secret - continue with the raiden flow - request the secret from the initiator b.iii - else (we got some kind of an error (connection, exception, etc) ) b.iii.1 - if current block is above expiration block - 2* reveal timeout continue with the raiden flow - request the secret from the initiator
b.iii.2 sleep 5 seconds b. back to b.

@kilrau @sangaman please confirm/comment

kilrau commented 5 years ago

Feedback:

a. if no resolver is configured - use normal raiden flow (target should ask initiator for the secret)

Definitely, everything should be raiden default if there is no resolver configured.

b. if resolver is configured - try to resolve:

Addition: try to resolve and retry in 1s (?) interval until there is a response.

b.i - if you got the secret - continue with the raiden flow - send the secret back to get the mediator/initiator.

Continue with the regular swap flow, but I guess that's what you mean.

b.ii- if you got a response that the resolver does not have the secret - continue with the raiden flow - request the secret from the initiator b.iii - else (we got some kind of an error (connection, exception, etc) ) b.iii.1 - if current block is above expiration block - 2* reveal timeout continue with the raiden flow - request the secret from the initiator b.iii.2 sleep 5 seconds b. back to b.

I believe raiden should handle this worst case too, otherwise caught in infinite loop: if request secret from the initiator fails, e.g. it's indeed a swap flow, xud crashed and for some reason lost the secret. xud comes back up, now tells raiden it doesn't have the secret (even though it should), raiden requests from initiator, but this one also does not have the secret. In this case there is no other way than to cancel the swap and payment.

offerm commented 5 years ago

In case both the target (xud) and the initiator do not have the secret, the payment is canceled after the timeout.

offerm commented 5 years ago

This is how it is today. What is new here is that if the resolver is configured the target raiden will keep trying to resolve and will not go back to the initiator until: a. the resolver confirms that it has not such secret b. getting close to the timeout.

No infinite loop here

kilrau commented 5 years ago

Ok. Last thing: in which intervals should raiden retry pulling the secret from xud? 1s?

offerm commented 5 years ago

As I wrote above:

b.iii.2 sleep 5 seconds

kilrau commented 5 years ago

I think it can be shorter, but yeah let's go for 5s for now. @sangaman Please give some feedback too.

sangaman commented 5 years ago

So the plan is: a. if no resolver is configured - use normal raiden flow (target should ask initiator for the secret) b. if resolver is configured - try to resolve: b.i - if you got the secret - continue with the raiden flow - send the secret back to get the mediator/initiator. b.ii- if you got a response that the resolver does not have the secret - continue with the raiden flow - request the secret from the initiator b.iii - else (we got some kind of an error (connection, exception, etc) ) b.iii.1 - if current block is above expiration block - 2* reveal timeout continue with the raiden flow - request the secret from the initiator b.iii.2 sleep 5 seconds b. back to b.

This plan looks good to me. The only part I'm not completely clear on is expiration block - 2* reveal timeout - my thinking is that we want to keep retrying xud until shortly before expiration. I think 5 seconds is fine too for a retry interval.

kilrau commented 5 years ago

Closed by https://github.com/ExchangeUnion/raiden/pull/13