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 issue is to explore and implement initial support and UI for the functionality envisioned by (in-progress) Bolt PR: "Add the ability to hold HTLCs before forwarding (FEAT 52/53) #989" and to help inform the process of standardization for async payments.
Support will be added to hold trampoline payments until triggered using custom messages between Eclair and Phoenix instead of using onion messages. We will use temporary/experimental feature bits and TLV tags for this phase of implementation.
eclair: support a new async_payment TLV in the onion payload of trampoline payments which causes the trampoline node to not relay a payment until triggered by a message that the receiver is online, canceled by the payment sender or timed out by the routing node itself. Added in PR# 2435
eclair: add a system for detecting when a peer is connected and all of its channels are communicating (eg. via a new LocalChannelUp message). Added in PR# 2464.
eclair: add a new singleton actor that will reply with a trigger message to actors that register to be notified when a specific peer is connected and ready to receive payments. See comment from t-bast. Added in PR #2491.
lightning-kmp: relax the payment receiver's cltv_expiry check between outer and trampoline onion payloads in order to be able to accept an async payment that was held by a trampoline node.
lightning-kmp: add the ability to create an async payment from a Bolt-11 invoice and a custom Lightning message to cancel a pending payment.
eclair: add support to trigger delivery of a pending trampoline payment when its destination Phoenix node re-connects to eclair
phoenix: add UI to support async payments
Once standardization work on #989 is complete we can implement the store and forward onion messages and feature bits envisioned for async payments. Integration testing could be made at this point with other nodes that implement async trampoline payments. Further work could then add PTLC and static invoice support.
The text was updated successfully, but these errors were encountered:
This issue is to explore and implement initial support and UI for the functionality envisioned by (in-progress) Bolt PR: "Add the ability to hold HTLCs before forwarding (FEAT 52/53) #989" and to help inform the process of standardization for async payments.
Support will be added to hold trampoline payments until triggered using custom messages between Eclair and Phoenix instead of using onion messages. We will use temporary/experimental feature bits and TLV tags for this phase of implementation.
async_payment
TLV in the onion payload of trampoline payments which causes the trampoline node to not relay a payment until triggered by a message that the receiver is online, canceled by the payment sender or timed out by the routing node itself. Added in PR# 2435LocalChannelUp
message). Added in PR# 2464.cltv_expiry
check between outer and trampoline onion payloads in order to be able to accept an async payment that was held by a trampoline node.Once standardization work on #989 is complete we can implement the store and forward onion messages and feature bits envisioned for async payments. Integration testing could be made at this point with other nodes that implement async trampoline payments. Further work could then add PTLC and static invoice support.
The text was updated successfully, but these errors were encountered: