I've been using the hold invoice RPCs from #150 (Bolt11ReceiveForHash, Bolt11ClaimForId, Bolt11FailForId) and the JIT channel receive from #143, and I noticed there's no way to use them together. Bolt11ReceiveViaJitChannel and Bolt11ReceiveVariableAmountViaJitChannel don't accept a payment hash, so the node always generates the preimage and claims the payment automatically.
This would be useful for cases where the receiver doesn't have inbound liquidity yet but still needs to decide whether to accept a payment. For example, a merchant confirming stock before settling an order, or a swap service that has to wait for an on-chain tx before releasing the preimage (the use case in ldk-node#597).
ldk-node already supports this since 0.7 (ldk-node#608):
receive_via_jit_channel_for_hash(amount_msat, description, expiry_secs,
max_total_lsp_fee_limit_msat, payment_hash)
receive_variable_amount_via_jit_channel_for_hash(description, expiry_secs, max_proportional_lsp_fee_limit_ppm_msat, payment_hash)
and ldk-server already sets manually_handle_unknown_bolt11_payments = true, so the PaymentClaimable event and claim/fail flow should work the same way.
Following the existing Bolt11Receive / Bolt11ReceiveForHash split, I was thinking of adding two new RPCs:
Bolt11ReceiveViaJitChannelForHash: same fields as Bolt11ReceiveViaJitChannelRequest
plus payment_hashBolt11ReceiveVariableAmountViaJitChannelForHash: same fields as
Bolt11ReceiveVariableAmountViaJitChannelRequest plus payment_hash
Both would return the invoice, like Bolt11ReceiveForHash does. I'd also add the matching CLI commands and an e2e test covering JIT receive for hash → PaymentClaimable → Bolt11ClaimForId.
One thing I'm not sure about: if the receiver fails the payment with Bolt11FailForId, the LSP may already have opened (or be about to broadcast) the channel without getting its fee. Is that something we should document or warn about, or is it expected to be handled on the LSP side?
I'd like to work on this if it sounds good. @benthecarman
I've been using the hold invoice RPCs from #150 (
Bolt11ReceiveForHash,Bolt11ClaimForId,Bolt11FailForId) and the JIT channel receive from #143, and I noticed there's no way to use them together.Bolt11ReceiveViaJitChannelandBolt11ReceiveVariableAmountViaJitChanneldon't accept a payment hash, so the node always generates the preimage and claims the payment automatically.This would be useful for cases where the receiver doesn't have inbound liquidity yet but still needs to decide whether to accept a payment. For example, a merchant confirming stock before settling an order, or a swap service that has to wait for an on-chain tx before releasing the preimage (the use case in ldk-node#597).
ldk-node already supports this since 0.7 (ldk-node#608):
and ldk-server already sets
manually_handle_unknown_bolt11_payments = true, so thePaymentClaimableevent and claim/fail flow should work the same way.Following the existing
Bolt11Receive/Bolt11ReceiveForHashsplit, I was thinking of adding two new RPCs:Bolt11ReceiveViaJitChannelForHash: same fields asBolt11ReceiveViaJitChannelRequestplus
payment_hashBolt11ReceiveVariableAmountViaJitChannelForHash: same fields asBolt11ReceiveVariableAmountViaJitChannelRequestpluspayment_hashBoth would return the invoice, like
Bolt11ReceiveForHashdoes. I'd also add the matching CLI commands and an e2e test covering JIT receive for hash →PaymentClaimable→Bolt11ClaimForId.One thing I'm not sure about: if the receiver fails the payment with
Bolt11FailForId, the LSP may already have opened (or be about to broadcast) the channel without getting its fee. Is that something we should document or warn about, or is it expected to be handled on the LSP side?I'd like to work on this if it sounds good. @benthecarman