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
This module will manage the accepted set of RFQ bundles. Using the HtlcInterceptor RPC call, it'll attempt to interecept any HTLCs that have an scid that matches the set of active rfq_scid. The set of active rfq_scid will need to be persisted to disk in a reliable manner. In addition to using the interceptor to reject HTLCs that match the rfq_scid but don't adhere to the accepted terms, we'll also need a background routine that removes expired quotes (all quotes expire after a period of time).
We'll also want a set of RPCs to introspect into this state, and potentially modify, or expire the set of accepted quotes early.
Accepting/rejecting incoming HTLCs
The order handler (manager) intercepts incoming HTLCs. It then and accepts/rejects each HTLC based on any associated channel remit.
A channel remit is a data structure that describes the payment conditions which must be satisfied before a particular HTLC can be accepted. The channel remits are organised (keyed) by short channel IDs (SCIDs).
These are the fields available to inspect an intercepted HTLC:
// InterceptedHtlc contains information about a htlc that was intercepted in// lnd's switch.typeInterceptedHtlcstruct {
// IncomingCircuitKey is lnd's unique identfier for the incoming htlc.IncomingCircuitKey invpkg.CircuitKey// Hash is the payment hash for the htlc. This may not be unique for// MPP htlcs.Hash lntypes.Hash// AmountInMsat is the incoming htlc amount.AmountInMsat lnwire.MilliSatoshi// AmountOutMsat is the outgoing htlc amount.AmountOutMsat lnwire.MilliSatoshi// IncomingExpiryHeight is the expiry height of the incoming htlc.IncomingExpiryHeightuint32// OutgoingExpiryHeight is the expiry height of the outgoing htlcs.OutgoingExpiryHeightuint32// OutgoingChannelID is the outgoing channel id proposed by the sender.// Since lnd has non-strict forwarding, this may not be the channel that// the htlc ends up being forwarded on.OutgoingChannelID lnwire.ShortChannelID
}
The final recipient node (which receives the tap asset) is only concerned with payments from the channel ID specified in the OutgoingChannelID field. Therefore, this is the channel ID that we must use to retrieve the corresponding channel remit data.
Before we can accept the HTLC, the sats amount specified by AmountOutMsat must be equal to or greater than the amount specified in the channel remit. The threshold sats amount specified in the channel remit is calculated from the target asset amount that the recipient node intends to receive and the accepted asset specific exchange rate (btc/asset).
The text was updated successfully, but these errors were encountered:
Parent issue: #683
Quoting the relevant section of the parent issue:
Accepting/rejecting incoming HTLCs
The order handler (manager) intercepts incoming HTLCs. It then and accepts/rejects each HTLC based on any associated channel remit.
A channel remit is a data structure that describes the payment conditions which must be satisfied before a particular HTLC can be accepted. The channel remits are organised (keyed) by short channel IDs (SCIDs).
These are the fields available to inspect an intercepted HTLC:
The final recipient node (which receives the tap asset) is only concerned with payments from the channel ID specified in the
OutgoingChannelID
field. Therefore, this is the channel ID that we must use to retrieve the corresponding channel remit data.Before we can accept the HTLC, the sats amount specified by
AmountOutMsat
must be equal to or greater than the amount specified in the channel remit. The threshold sats amount specified in the channel remit is calculated from the target asset amount that the recipient node intends to receive and the accepted asset specific exchange rate (btc/asset
).The text was updated successfully, but these errors were encountered: