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
Today we have the HtlcInterceptor which is useful for modifying the default forwarding behavior of an lnd node. Callers of the RPC get a call back like construct that they can use to accept/deny forwarding attempts. However, we don't have such an option for the exit hop, as that logic bypasses the HltcSwitch and will be sent directly to the InvoiceRegistry.We should add a new interceptor-like RPC call, the InvoiceAcceptor, which can be used to modify why/how lnd accepts a payment as a final hop.
One example use case is the popular "JIT channel" construct where a channel is opened on the fly to allow the final hop to accept a payment. In typical instantiations, the receiver might actually get an HTLC with an amount below the original invoice. Service providers can use this little trick to collect a service fee as they provided inbound capacity to the target node.
The existing hodl invoice RPC call partially fills this gap, but today we don't yet have a good way of subscribing to all the active hodl invoices (#3120).
Ensure that the normal invoice checking logic (expiry check etc.) is still executed.
The interceptor should be able to bypass checks that would reject settling an invoice based on amt. Ensure that that's possible with the new interceptor.
If the interceptor decrees, then an exit hop HTLC should be accepted.
Checkout updateMpp. Ensure that the total settled amount is correct given the interceptor client response.
I think the "accept" notion is used to accept a HTLC which doesn't settle the entire amount of the invoice. Where as in settling we loop over all "accepted" HTLCs associated with an invoice, and if the amount is sufficient, those accepted HTLCs become settled.
Today we have the
HtlcInterceptor
which is useful for modifying the default forwarding behavior of anlnd
node. Callers of the RPC get a call back like construct that they can use to accept/deny forwarding attempts. However, we don't have such an option for the exit hop, as that logic bypasses theHltcSwitch
and will be sent directly to theInvoiceRegistry
.We should add a new interceptor-like RPC call, theInvoiceAcceptor
, which can be used to modify why/howlnd
accepts a payment as a final hop.One example use case is the popular "JIT channel" construct where a channel is opened on the fly to allow the final hop to accept a payment. In typical instantiations, the receiver might actually get an HTLC with an amount below the original invoice. Service providers can use this little trick to collect a service fee as they provided inbound capacity to the target node.
The existing hodl invoice RPC call partially fills this gap, but today we don't yet have a good way of subscribing to all the active hodl invoices (#3120).
Steps To Completion
NotifyExitHopHTLC
call, add a way for an external subscriber to make decisions w.r.t settling the invoice with priority over the existing logic. The caller should be able to return anHtlcResolution
which is executed in line with the existing logic.HtlcInterceptor
andFundingAcceptor
as inspiration.The text was updated successfully, but these errors were encountered: