liquidity: add swap type and loop in fee logic #433
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1 task
Contributor
Author
|
Split up #419 into 2 parts for easier review. Follow up PR is up (just one unit test needs fixing) for reference of how this will be used. I intend to merge them at the same time, since this doesn't really add much functionality, just easier to split early IMO. |
arshbot
suggested changes
Nov 29, 2021
Contributor
arshbot
left a comment
arshbot
left a comment
There was a problem hiding this comment.
A necessary PR, love the inclusion of loop in's to the accounting stuff, that'll be useful to a lot of people. Left some minor nits and context qs
carlaKC
force-pushed
the
419-swaptype
branch
from
f3b6825 to
d147ac6
Compare
Contributor
Author
|
@bhandras PTAL! |
bhandras
approved these changes
Nov 29, 2021
| switch rule.Type { | ||
| case swap.TypeOut: | ||
| builder = newLoopOutBuilder(m.cfg) | ||
| restrictions = outRestrictions |
Member
There was a problem hiding this comment.
nit: I'd keep the incoming outRestrictions arg with it's old name (restrictions) instead.
carlaKC
force-pushed
the
419-swaptype
branch
2 times, most recently
from
9925339 to
37ce888
Compare
The current wording in this function is very specific to loop out. In this commit, we refactor to use `target` and `reserve` rather than inbound and outbound so that it can be used more generically.
In preparation for adding loop in swaps, we relate liquidity rules to a specific type of swap that we want to dispatch. This allows us to use a single rule format for multiple swap types.
In preparation of supporting multiple swap types, we move our swap builder into a single place, so that we can check our `maySwap` restriction per-swap (since we'll now have different checks for different swap types. To save ourselves from making multiple calls to the loop server for the restrictions placed on each swap type, we still pass a single set of restrictions in.
Add an implementation of our swap interface which can be used for loop in, and fee estimation. For fee estimation, we always want to calculate worst case loop in fees, so that autoloop never goes over its budget. However, for loop in we can't estimate how much a timeout would cost, because we must sweep the output (can't set a limit like loop out), and fee estimation in a few hundred blocks (when we'd sweep the timeout) is totally unreliable. Instead, we use a high fee rate as our best-effort fee rate for the future. We can also be confident that that loop in swaps will succeed, since once the htlc is locked in, all that is required is for the server to sweep.
carlaKC
force-pushed
the
419-swaptype
branch
from
37ce888 to
8113c34
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR does some preliminary work for adding autoloopin support. Primarily adding a swap type to our liquidity rules, and implementing some of the fees + budgeting plumbing we need.
Pull Request Checklist
release_notes.mdif your PR contains major features, breaking changes or bugfixes