-
Notifications
You must be signed in to change notification settings - Fork 45
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
Trampoline payments #1034
Trampoline payments #1034
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.
Looking good. I would suggest also:
- Checking that the LSP can do trampoline payments (via an LSPInformation flag?)
- Having a config option to not use trampoline payments (for privacy preserving)
- Is it worth prechecking the outbound liquidity to the LSP before the trampoline payment or can the LSP more efficiently do that? (This is think about the edge case of switching LSP and maybe most/all of the liquidity is still with the old LSP)
Good points @dangeross . |
8a68398
to
5371c3c
Compare
@dangeross @roeierez please check my last 7 commits.
With these two pieces of information we can check:
Next to that I added a flag in the SendPaymentRequest and LnurlPayRequest to signal the user doesn't want to use trampoline. |
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.
Looking good @JssDWt
libs/sdk-core/src/breez_services.rs
Outdated
let features = self | ||
.node_api | ||
.connect_peer(node_id.clone(), address.clone()) | ||
.await | ||
.map_err(|e| SdkError::ServiceConnectivity { | ||
err: format!("(LSP: {node_id}) Failed to connect: {e}"), | ||
})?; | ||
node_state.connected_peers.push(ConnectedPeer { | ||
id: node_id.clone(), | ||
features, | ||
}); | ||
self.persister.set_node_state(&node_state)?; |
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'm wondering if updating the node_state's connected peers could done in node_api.connect_peer()
, but AFAIK this is the only time its called
I had a case where the trampoline payment was not attempted. I don't think this mechanism is robust enough. Maybe the peer feature check has to be removed? |
The status of this PR today is:
|
38d0eaf
to
dfccdd6
Compare
bd8b83f
to
11607cd
Compare
|
Re-requesting review from @roeierez and @dangeross |
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 I think, just 2 issues with the comments
11607cd
to
6417851
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.
I imagine at some point people will ask about LSP trampoline fees. Maybe we should follow up at some point to add the fee rate to the LSP info?
Yes. |
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!
libs/sdk-core/src/breez_services.rs
Outdated
self.persister.set_lsp_id(lsp.id)?; | ||
self.persister.set_lsp_pubkey(lsp.pubkey.clone())?; |
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.
As it seems these functions are always being called together now, perhaps better to have one function that takes these two arguments?
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.
This is currently in 2 places, and setting lsp id without pubkey is in one place here. If you still think we should make that a single function, I'll fix that. We could make the function check whether the new lsp id is the same, if it's not, erase the lsp pubkey if not supplied.
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 see, I missed that. Then it is less priority but I think it is slightly better to have one function.
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.
Now setting these in a single function in 4a0a150
// TODO: Ensure this works with trampoline payments | ||
// NOTE: If this doesn't work with trampoline payments, the sync also | ||
// needs updating. | ||
let payment = Self::fetch_outgoing_payment_with_retry(client, result.payment_hash).await?; |
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.
About the comment, do we know if that works with trampoline?
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.
Not yet, for that we need the transport error to be resolved.
|
||
// For trampoline payments the amount_msat doesn't match the actual | ||
// amount. If it's a trampoline payment, take the amount from the label. | ||
let (payment_amount, client_label) = serde_json::from_str::<PaymentLabel>(payment.label()) |
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.
Do we have the bolt11 we paid in case of trampoline? If so perhaps better to take the amount from there? If we don't perhaps it is better to persist it as part of the label? I think from UX perspective the user needs the paid invoice.
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.
The invoice is there, but possibly it's a zero amount invoice (which we support). Having the amount in the label handles both cases.
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.
Right. I think we have a mechanism that adds the amount (in case of zero invoice) to the extrenal_info (persist_pending_payment).
But I am not against of having that in the label which I think is better.
@dangeross re-requesting review due to this added commit: 4a0a150 |
4a0a150
to
bfbe095
Compare
Bumped greenlight because Blockstream/greenlight#475 was merged |
extract trampoline payment data from label
This update ensures that lsp pubkey and lsp id are always set in the same call. Sometimes the lsp pubkey is not yet available. Then only the lsp id will be set. If the lsp id changes, the pubkey is then removed. If the lsp id remains the same, the node pubkey will still be persisted.
bfbe095
to
985bfed
Compare
Changes introduced in: breez/breez-sdk-greenlight#1034
Changes introduced in: breez/breez-sdk-greenlight#1034
Changes introduced in: breez/breez-sdk-greenlight#1034
This PR adds trampoline payment functionality to the SDK.
If a client sends a payment, normally the greenlight node will find routes through the gossip graph, and attempt to pay over those routes. If a route fails, it tries again. For every attempt there are multiple rounds where the greenlight node has to communicate with the signer. Trampoline payments have the advantage there will be only one outgoing payment attempt, and the LSP will do the retrying, therefore less communication rounds are necessary, hopefully improving payment performance. The tradeoff is the user may pay more fees for the route, and the user loses some privacy in the current setup, because the LSP will learn the payment destination. The initial default trampoline policy will be 0,5%.
This PR leans on the corresponding greenlight PR for trampoline payments, which is still a work in process: Blockstream/greenlight#475
The LSP will need to run this plugin: https://github.com/breez/trampoline
Some notes about this PR:
listpays
. That's nice, because it doesn't require any changes to sync. The payments fromlistpays
have the wrongamount_msat
due to the way trampoline payments work. We solve that by putting the actual amount in a payment label for trampoline payments.TODO: