Burak Keceli [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-24 🗒️ Summary of this message: Lightning ...
đź“… Original date posted:2023-05-24
🗒️ Summary of this message: Lightning Network's zero-conf channel has risks as users have to wait for confirmation before revealing preimage for payment. Ark's ATLCs ensure atomicity without waiting for confirmations.
đź“ť Original message:> You can also do the same in Lightning, with the same risk profile: the LSP opens a 0-conf channel to you, you receive over Lightning, send out over Lightning again, without waiting for onchain confirmations.
This is not correct. If an LSP opens a zero-conf channel to me, I cannot receive over lightning immediately because I have to wait for that channel to confirm before revealing my preimage for the payment. If I don’t, LSP takes the sender’s money yet double-spends my channel.
This is not the case with Ark. Ark ensures "absolute atomicity" by using ATLCs instead of HTLCs. Users can receive payments and forward them further without waiting for on-chain confirmations. A double-spend attempt breaks the entire atomicity. An ASP cannot redeem senders’ vTXO(s) if they double-spend recipients' vTXO(s).
🗒️ Summary of this message: Lightning Network's zero-conf channel has risks as users have to wait for confirmation before revealing preimage for payment. Ark's ATLCs ensure atomicity without waiting for confirmations.
đź“ť Original message:> You can also do the same in Lightning, with the same risk profile: the LSP opens a 0-conf channel to you, you receive over Lightning, send out over Lightning again, without waiting for onchain confirmations.
This is not correct. If an LSP opens a zero-conf channel to me, I cannot receive over lightning immediately because I have to wait for that channel to confirm before revealing my preimage for the payment. If I don’t, LSP takes the sender’s money yet double-spends my channel.
This is not the case with Ark. Ark ensures "absolute atomicity" by using ATLCs instead of HTLCs. Users can receive payments and forward them further without waiting for on-chain confirmations. A double-spend attempt breaks the entire atomicity. An ASP cannot redeem senders’ vTXO(s) if they double-spend recipients' vTXO(s).