Blinded fees #967
Blinded fees #967
Conversation
Route blinding allows a recipient to provide a blinded route to potential payers. Each node_id in the route is tweaked, and dummy hops may be included. This is an alternative to rendezvous to preserve recipient anonymity. It has a different set of trade-offs: onions are re-usable, but the privacy guarantees are a bit weaker and require more work (e.g. when handling errors).
As suggested by @lightning-developer
| 1. type: 12 (`outgoing_cltv_value`) | ||
| 2. data: | ||
| * [`tu32`:`outgoing_cltv_value`] |
There was a problem hiding this comment.
There could be cases where we wouldn't want to force the payer to pay immediately in which case we could use a delta here that we would add to the outgoing_cltv_value from the tlv_payload.
That is not needed for offers however as the invoice should be paid immediately after receiving it (the decision to pay is taken before, when requesting the invoice).
|
This doesn't really work, since the sender has to compute the fees based on the HTLCs it is sending. This makes this proposal unsuitable for spontaneous payments or amountless invoices. More importantly however it doesn't work for any payment that might require splitting a payment into multiple HTLCs, since the fees are dependent on the amount being routed. As it is the sender cannot compute the fees to add to its HTLCs, unless I'm overlooking something. |
This assumes that the recipient knows the amount that is being sent and creates a blinding route for that amount which I think is a perfectly reasonable assumption. The two use cases that you mention (spontaneous payments and amountless invoices) are already handled by offers in a way that is compatible with my proposal. If there is an important use case that requires the recipient not knowing the amount in advance (and I don't think there should be any when we have offers), we can just put the fee structure in the blinded route instead of the already computed fee (and similarly with CLTV, you can put the delta in the blinded route instead of the absolute value), I just think that these blinded routes should be single use.
That is solved by trampoline.
That's the point, the sender is responsible for the fees to the start of the blinded route and the recipient is responsible for the fees inside the blinded route. |
|
Closing this PR as it has been intergated into #765 |
Builds on top of #765.
Makes blinded routes more private by including the fees and CLTV inside the blinded route so the recipient doesn't need to leak it to the payer.