-
Notifications
You must be signed in to change notification settings - Fork 4
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
Send & Chain: Localize refund flow to swap handlers #407
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think by not explicitly checking the swap expiration and first relying on the swap state you are assuming Boltz is always being compliant (or functional). If swap a state is not changed to RefundPending (for outgoing chain/send swaps) in the stream updates, then there is never an attempt to refund
@hydra-yse IMO the coopertive refund which should in theory always succeed should be executed immeditely as soon as we understand we need it so having it as part of the status stream as before makes sense to me. |
0331653
to
1706772
Compare
The code as is is not clear and hard to understand (not because of this PR) so I certainly understand the motivation to do some cleanup here.
Now our two cases can use the above functinoality:
What do you think @hydra-yse ? |
1706772
to
07cf95b
Compare
There are still some checks/tests to do, so I will be leaving it as draft for now, though I would appreciate a review on the interface changes 😄 . @roeierez I'll clarify later today why I think creating a separate |
69518c6
to
9113ce1
Compare
@dangeross I've also addressed Pending swap tracking in 9113ce1, so that even if Boltz doesn't return the right state we can still try non-cooperatively after the expiry. Just have to propagate the changes to chain swaps. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks a lot better IMO. I also like the fact that every module (chainswap, send_swap) takes care of its own refunds.
I still need to do another pass.
9113ce1
to
528a6db
Compare
A note about 2d65bbb: I think waiting 10 minutes is a reasonable tradeoff which ends up saving us both bandwidth and computation time. Since the current method attempts a non-cooperative refund even when the swap is |
528a6db
to
2d65bbb
Compare
feat: add background thread cooperative refunding feat: simplify refund flow and isolate to state handler fix: rename `StateHandler` to `Handler` fix: dart doc fix: consider Pending swaps when refunding feat: add creation time check before swap expiry Setting a wait time of 10 minutes avoids fetching chain data and some extra computation each time the background thread picks up on the swap feat: isolate refund flow to swap handlers feat: add `get_transaction_hex` method
9b4e5b5
to
b220766
Compare
Some(&refund_tx_id), | ||
) | ||
.await?; | ||
match swap.user_lockup_tx_id { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a comment for @dangeross, I've reverted the script history check here to avoid re-fetching. It occurs anyway when reconstructing the refund transaction (utils::new_lbtc_refund_tx
) so there shouldn't be any problems there.
b220766
to
f5e4f40
Compare
@hydra-yse is this ready for another review? If so can you please rebase the conflicts? |
9090ef9
to
c8de986
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
1e596da
to
5a04999
Compare
7a600bb
to
74f4428
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
913cb37
to
f3dd5e6
Compare
This PR aims at fixing the refund flow loop, since it used to block the status stream thread while waiting for lockups to be confirmed. The logic has been moved to the swap handlers, so they are now independent from the swapper (currently only used for broadcasting). The logic for constructing the refund tx (only Liquid) has also been moved to the SDK side due to problems with lowball, and the requirement to fetch from our Esplora.
The current improvements make cooperative refunds happen almost instantaneously, and with no reliance on the swapper. In case of no Boltz status update, they will be refunded non-cooperatively on locktime expiry (via
LiquidSdk::track_pending_swaps
).