Burak Keceli [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-23 🗒️ Summary of this message: Lightning ...
📅 Original date posted:2023-05-23
🗒️ Summary of this message: Lightning payments are routed through ASPs, which may fail to forward payments on the broader network, causing recipients to be unable to rely on received funds until the next pool transaction is confirmed. However, Ark allows users to pay lightning invoices with zero-conf vTXOs collaboratively. Swap-ins require users to wait for on-chain confirmations to avoid double-spending.
📝 Original message:> As the access to Lightning is also by the (same?) ASP, it seems to me that the ASP will simply fail to forward the payment on the broader Lightning network after it has replaced the in-mempool transaction, preventing recipients from actually being able to rely on any received funds existing until the next pool transaction is confirmed.
Yes, that's correct. Lightning payments are routed through ASPs. ASP may not cooperate in forwarding HTLC(s) AFTER double-spending their pool transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE double-spending their pool transaction.
What makes Ark magical is, in the collaborative case, users' ability to pay lightning invoices with their zero-conf vTXOs, without waiting for on-chain confirmations.
This is the opposite of swap-ins, where users SHOULD wait for on-chain confirmations before revealing their preimage of the HODL invoice; otherwise, the swap service provider can steal users' sats by double-spending their zero-conf HTLC.
🗒️ Summary of this message: Lightning payments are routed through ASPs, which may fail to forward payments on the broader network, causing recipients to be unable to rely on received funds until the next pool transaction is confirmed. However, Ark allows users to pay lightning invoices with zero-conf vTXOs collaboratively. Swap-ins require users to wait for on-chain confirmations to avoid double-spending.
📝 Original message:> As the access to Lightning is also by the (same?) ASP, it seems to me that the ASP will simply fail to forward the payment on the broader Lightning network after it has replaced the in-mempool transaction, preventing recipients from actually being able to rely on any received funds existing until the next pool transaction is confirmed.
Yes, that's correct. Lightning payments are routed through ASPs. ASP may not cooperate in forwarding HTLC(s) AFTER double-spending their pool transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE double-spending their pool transaction.
What makes Ark magical is, in the collaborative case, users' ability to pay lightning invoices with their zero-conf vTXOs, without waiting for on-chain confirmations.
This is the opposite of swap-ins, where users SHOULD wait for on-chain confirmations before revealing their preimage of the HODL invoice; otherwise, the swap service provider can steal users' sats by double-spending their zero-conf HTLC.