As discussed in detail about forwardable peerswaps, these need to be added to the protocol so that forwarders can decide whether it is safe to further forward the peerswap, or if it has to be handled here.
first_csv_expiry is the R parameter currently hardcoded to 1008 for Bitcoin and 60 for Liquid.
min_final_cltv_expiry promises to issue the invoice with the c field set to that value.
In the forwarding case, a potential forwarder MUST:
Check first_csv_expiry > min_final_cltv_expiry.
Check that first_csv_expiry - min_final_cltv_expiry > 504.
If it decides to forward, check first_csv_expiry - min_final_cltv_expiry > 504 + cltv_delta, where cltv_delta is the parameter it uses for channels.
If it decides to forward, it should forward the next hop min_final_cltv_expiry to the received min_final_cltv_expiry + cltv_delta,
As discussed in detail about forwardable peerswaps, these need to be added to the protocol so that forwarders can decide whether it is safe to further forward the peerswap, or if it has to be handled here.
first_csv_expiryis theRparameter currently hardcoded to 1008 for Bitcoin and 60 for Liquid.min_final_cltv_expirypromises to issue the invoice with thecfield set to that value.In the forwarding case, a potential forwarder MUST:
first_csv_expiry > min_final_cltv_expiry.first_csv_expiry - min_final_cltv_expiry > 504.first_csv_expiry - min_final_cltv_expiry > 504 + cltv_delta, wherecltv_deltais the parameter it uses for channels.min_final_cltv_expiryto the receivedmin_final_cltv_expiry + cltv_delta,