Skip to content

[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

Open
1 of 3 tasks
GeorgeTsagk opened this issue Feb 6, 2025 · 6 comments · May be fixed by #1457
Open
1 of 3 tasks

[feature]: Multi-RFQ receive #1359

GeorgeTsagk opened this issue Feb 6, 2025 · 6 comments · May be fixed by #1457
Assignees
Milestone

Comments

@GeorgeTsagk
Copy link
Member

GeorgeTsagk commented Feb 6, 2025

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:

  • Even if we did acquire multiple RFQs before creating the invoice, how can we encode them all in the Bolt11 format
  • Use blinded paths, which can give up to 3 entry points (possibility for 3 RFQs?)
  • Present multiple RFQ with interactive bolt12 offer communication
@GeorgeTsagk
Copy link
Member Author

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

@ZZiigguurraatt
Copy link

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.

@ZZiigguurraatt
Copy link

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?

@ZZiigguurraatt
Copy link

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.

@GeorgeTsagk
Copy link
Member Author

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?

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.

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.

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.

@ZZiigguurraatt
Copy link

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.

I think we always have to pick the worst quote regardless of the spread, but I agree that

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.

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.

@levmi levmi added this to the v0.6 milestone May 8, 2025
@levmi levmi added the P0 label May 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🔖 Ready
Development

Successfully merging a pull request may close this issue.

3 participants