ensure payee and add expected payout height #31
Conversation
JssDWt
force-pushed
the
jssdwt-ensure-payee
branch
from
decfb78 to
a2b04ed
Compare
JssDWt
force-pushed
the
jssdwt-swap-size
branch
from
143520c to
2ab2f67
Compare
JssDWt
force-pushed
the
jssdwt-ensure-payee
branch
2 times, most recently
from
3ed44ef to
7521067
Compare
JssDWt
force-pushed
the
jssdwt-swap-size
branch
from
2ab2f67 to
b3d8d25
Compare
JssDWt
force-pushed
the
jssdwt-ensure-payee
branch
from
7521067 to
d68e6f9
Compare
JssDWt
force-pushed
the
jssdwt-ensure-payee
branch
from
d68e6f9 to
f326d20
Compare
| @@ -259,6 +289,10 @@ where | |||
|
|
|||
| let hash = invoice.payment_hash(); | |||
| let swap_state = self.swap_repository.get_swap_by_hash(hash).await?; | |||
| if swap_state.swap.destination != invoice.get_payee_pub_key() { | |||
There was a problem hiding this comment.
What is the reason for validating the destination? Should we validate the payout window by calculating the route again?
There was a problem hiding this comment.
I wanted to make sure that only the swap requester can get paid for the swap. Thinking about it again maybe the preimage is enough certainty and we don't even have to check the destination?
| // invoice should have equivalent values for routing hints and | ||
| // min_final_cltv_expiry_delta as the eventual invoice used for payout, so | ||
| // the swap server can give a good estimate of fees and timeouts. | ||
| string invoice = 3; |
There was a problem hiding this comment.
I do understand the explanation above but it seems a bit odd to require the client to pass two invoices. One here and a different one in the pay_swap. Perhaps we can make the second one optional?
There was a problem hiding this comment.
I agree it's odd. Just an invoice contains the information we want to use. Destination, route hints, min_final_cltv_expiry delta, signature.
We could make the invoice for payout optional, but actually the client would always send the invoice for payout I think. Now the swap server doesn't have to persist the invoice along with the swap. I think that's a feature.
The client adds a random invoice to the create_swap request.
From that random invoice the final cltv, the destination and the expected route to the destination are extracted.
Now create_swap returns the expected last payout height for indication when the last payout time is.
Also it is now enforced that the destination of the swap payout is the same as the one that created it.