-
Notifications
You must be signed in to change notification settings - Fork 132
[feature]: Multi-RFQ receive #1359
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
Comments
Bolt11 route hints are imported to the graph used for pathfinding throughout the payment's lifecycle, as seen lnd/routing/payment_session.go This means, that we should be able to acquire multiple quotes from our peers, and encode multiple RFQ scids in the invoice, giving more routing options to the sender |
It seems we have another motivation for this in that we can get a competitive bid from the peers as well and choose the peers with best rates to include in the route hints. |
We also need to consider multi path payments. Do we want to request a quote for the full invoice amount with each peer or do we want to intentionally request a lesser amount with each peer so that the sender MUST use multi part payments and split the payment across several peers? |
Another thing to consider is when defining the SATS amount in the invoice that is given to the sender, we need to use the worst quote of all the peers. In this case, if the sender happens to pay through the peer with the best quote, we will get some bonus assets. |
Yeah that's a good point, I think we definitely need to over-quote, otherwise the sender would never be able to guess the exact amounts for each hop.
Also great point, we'd have to have some smart logic involved here, perhaps pick the worse rate only if there's a small spread over the quotes. If a peer provides me with a quote that deviates by more than a certain percentage/threshold, I'd rather kick him out of the "quote set" than include him. |
I think we always have to pick the worst quote regardless of the spread, but I agree that
but say we have one quote that is way better than all the others, we probably don't want to throw that one out just because it deviates a lot (unless we think that node is going to have low reliability of forwarding payments). It seems like we would want to keep it and if we are lucky and get a better deal then we'll take it. But we do want to throw out quotes that are much worse than all the others. |
Description
When generating an invoice, we are restricted to a specific assetID and a single peer. Even if that peer agreed on an RFQ quote with us, they may never be able to forward the payment to us because of their inbound. We should investigate ways of encoding multiple RFQs / entry-points to tapd and escape the single link bottleneck.
Similar to Multi-RFQ send, but a bit more difficult as we need to create a bolt11 compatible invoice that will be payable by all LN implementations, so we can't pull a lot of custom tricks. Multi-RFQ send has the convenience of being resolved within the scope of the local
tapd
<>lnd
.Items to investigate:
Use blinded paths, which can give up to 3 entry points (possibility for 3 RFQs?)Present multiple RFQ with interactive bolt12 offer communicationThe text was updated successfully, but these errors were encountered: