Skip to content
This repository has been archived by the owner on Jan 10, 2025. It is now read-only.

Onion Oracles for JIT Channels, MPP, and var-amount invoices. #25

Closed
ZmnSCPxj-jr opened this issue Apr 4, 2023 · 1 comment
Closed

Comments

@ZmnSCPxj-jr
Copy link
Contributor

#22 (comment)

FUTURE Idea that will not be added to this pull request, but should be written down somewhere anyway: onion oracles. Currently in the LSPS3 spec the plan is to offer clients a choice of MPP+fixed-amount-invoice vs no-MPP+var-amount-invoice. One way to get around the above dichotomy is to hand over payment onions (without an HTLC or even without a channel with the client) from the LSP to the client, then have the client report back the actual amount of the payment to the LSP, so that the LSP can wait for MPP on behalf of the client until the entire MPP has arrived.

The plan talked about in the group is to have a straightforward LSP->client query where the client reports the amount and the LSP gathers all HTLCs with the same hash until the amount is met, but this will not work in a PTLC universe where each outgoing PTLC is going to have a different point. So instead of that, my counterproposal is to have the LSP hand over the onions and give a unique identifier to each H/PTLC that would have gone to the client. The client then decodes the onion(s) and is the one that determines if the payment amount has been met, without revealing this data to the LSP. The client can then give the LSP a list of unique identifiers for H/PTLCs that form a single atomic payment, so that the LSP can build the channel and forward those H/PTLCs, minus the opening fee.

This was referenced Apr 14, 2023
@tnull
Copy link
Collaborator

tnull commented Jan 10, 2025

Closing this as this repository will be archived shortly. Please reopen on the bLIP repository if still relevant.

@tnull tnull closed this as completed Jan 10, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants