Expose updated swap fees for user review

[danielgranhao]

Partly resolves #602

With this PR:

• Users can provide an onchain fee rate leeway in sat/vbyte that they are fine with
• When auto-accepting isn't possible, the payment gets into the new WaitingFeeAcceptance state. It will stay there until the user accepts the new fee, refunds the swap, or the swap expires
• Listing payments waiting for review is done using the existing method list_payments
• users can accept the new fees, proceeding with the payment. Otherwise, they can immediately refund the swap.

[roeierez]

I Very like the concept! Added some comments.

[roeierez]

Looks good to me, only brainstorming naming conventions.

[danielgranhao]

This will need to be rebased on top of #620 in order for payments WaitingFeeAcceptance to be shown in the payments list. The core logic proposed here can already be reviewed though.

Also, I propose we update the notification plugins in a separate PR.

[roeierez]

@danielgranhao I did an initial pass and it looks solid to me, both the interface and the implementation. I still need to dig more into the code.
I think we need also to add a sync trigger when the payer_amount/receiver_amount changes now that we have the realtime sync in place.

[danielgranhao]

@roeierez Thanks! In the meantime, I've also identified some minor issues that need fixing. Once it's ready, I'll mark it.

[dangeross]

I think we should be able to recover the WaitingFeeAcceptance state, if there is only a user lockup tx and the swap payer/receive amount is 0

[danielgranhao]

I think we should be able to recover the WaitingFeeAcceptance state, if there is only a user lockup tx and the swap payer/receive amount is 0

@dangeross Hm.. I don't think so. Those conditions would still apply even after the user accepts the fees, after which the state should be Pending. IIUC, the WaitingFeeAcceptance state requires info from the swapper service, and cannot be determined from onchain data and local state alone. But I could be missing something

[roeierez]

I think we should be able to recover the WaitingFeeAcceptance state, if there is only a user lockup tx and the swap payer/receive amount is 0

@dangeross we had a discussion previously this week and decided to only transition to WaitingFeeAcceptance at the initiator end (local swap). This way the call to action will only be decided there and the rest of the synced devices will see the payment as pending. This is mainly for simplicity. Do you see any issue with that?

[dangeross]

Those conditions would still apply even after the user accepts the fees, after which the state should be Pending

If there is no server lockup tx, a user lockup tx and 0 amount it could be determined to be WaitingFeeAcceptance. Once accepted the payer/receiver amounts are updated and we should see a server lockup tx, then we could move on to Pending

[dangeross]

Do you see any issue with that?

I can't think of an issue

[danielgranhao]

If there is no server lockup tx, a user lockup tx and 0 amount it could be determined to be WaitingFeeAcceptance

The issue is we want to update the amount before moving to WaitingFeeAcceptance so that we can show the user the value of the payment waiting for fee acceptance. We would have to persist some additional data, like the fact that fees have been accepted, in order to distinguish between both states. Maybe that's the way forward?

[roeierez]

If there is no server lockup tx, a user lockup tx and 0 amount it could be determined to be WaitingFeeAcceptance

The issue is we want to update the amount before moving to WaitingFeeAcceptance so that we can show the user the value of the payment waiting for fee acceptance. We would have to persist some additional data, like the fact that fees have been accepted, in order to distinguish between both states. Maybe that's the way forward?

IMO your idea makes sense @danielgranhao. Perhaps keep the suggested amount (quote) as a different field (or table)? And only update the amount after the user accepts?

[dangeross]

to update the amount before moving to WaitingFeeAcceptance so that we can show the user the value of the payment waiting for fee acceptance

I just wonder how often the pair fee updates and what will happen if we accept a quote from a previous pair fee and it fails

[danielgranhao]

to update the amount before moving to WaitingFeeAcceptance so that we can show the user the value of the payment waiting for fee acceptance

I just wonder how often the pair fee updates and what will happen if we accept a quote from a previous pair fee and it fails

Pretty often as far as I can see. The current implementation of the accept method already checks the fees to see if they changed, returning an error in that case. Also, we can update the amount only after getting a success response from the swapper.

[danielgranhao]

Perhaps keep the suggested amount (quote) as a different field (or table)? And only update the amount after the user accepts?

I propose we separately persist over/underpayment amounts (sent by the payer and final receiver amount). Persisting the quote IMO is unnecessary because quotes are short-lived. Also, this approach already paves the way toward addressing #632, and would allow us in the future to expose requested_amount vs actual_paid_amount, in case we find that interesting.

Check out cd04f8c.

[roeierez]

Check out cd04f8c.

@danielgranhao I think your suggestion makes sense, I went over the code and it looks good.
Two things I think we should consider:

1. Fetching the user_lockup_amount in the recoverer instead of syncing it.
2. Consider again whether we need to sync the final_receiver_amount (Since this is an amount of a wallet tx we already have).

What do you think?

[danielgranhao]

@roeierez

1. Fetching the user_lockup_amount in the recoverer instead of syncing it.

Makes sense. I'll prepare a fix.

2. Consider again whether we need to sync the final_receiver_amount (Since this is an amount of a wallet tx we already have).

I see your point. The name isn't the best. It represents the value we expect to receive, given the quote we agreed upon, so it needs to be synced (accepted quotes aren't recoverable). We can replace it with the accepted quote to improve clarity.

[roeierez]

I see your point. The name isn't the best. It represents the value we expect to receive, given the quote we agreed upon, so it needs to be synced (accepted quotes aren't recoverable). We can replace it with the accepted quote to improve clarity.

I see. So it is basically the dynamic replacement for the static field "receiver_amount" ?
Can you elaborate what is the use for this field in the sdk? Is it to verify we expects before we claim?

[danielgranhao]

I see your point. The name isn't the best. It represents the value we expect to receive, given the quote we agreed upon, so it needs to be synced (accepted quotes aren't recoverable). We can replace it with the accepted quote to improve clarity.

I see. So it is basically the dynamic replacement for the static field "receiver_amount" ? Can you elaborate what is the use for this field in the sdk? Is it to verify we expects before we claim?

As we discussed out of band, the purpose was to show to the user the amount he will get in the time between acceptance and confirmation. But I was missing verification, which I've added now and also uses this amount.

The actual_payer_amount_sat (previously actual_user_lockup_amount_sat) is now recovered instead of synced.