You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 10, 2025. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
#22 (comment)
The text was updated successfully, but these errors were encountered: