ffranr
commented
2 months ago This RPC endpoint should return a status channel instead of directly providing an invoice, given that invoice generation can be time-consuming due to processes like RFQ negotiation, universe synchronization, and calls to LND. Implementing a status channel in this endpoint will prevent the caller from being blocked while these operations are executed.
dstadulis
Description
This issue proposes the implementation of a new RPC endpoint to facilitate generating a lightning network invoice for receiving tap assets over a lightning channel.
Arguments
The RPC endpoint should accept the following parameters:
AssetId: Identifier for the asset the receiving node wishes to receive.Amt: Amount of the specified asset that the receiving node wishes to receive.RoutingPeer: A serialized, compressed Bitcoin public key (route.Vertex) identifying the routing peer. This peer acts as the final hop in the BTC payment channel, converting BTC into theAssetIdand paying the invoice-generating node in the specified tap asset.Invoice Generation Functionality
The
tapdnode should execute the following steps to generate an invoice:AssetId. If the asset is unknown, retrieve asset details from a known universe.scid(short channel ID) for the invoice, the BTC amount to be used in the invoice, and the final expiry time of the invoice.lndto generate an invoice based on the agreed terms.The endpoint should return the modified lightning invoice to the caller.