📅 Original date posted:2023-05-23
🗒️ Summary of this message: A discussion on the potential risks of using Lightning Network and Atomic Swap Protocol (ASP) for Bitcoin transactions without waiting for on-chain confirmations.
📝 Original message:Do you have any write up that presents a fully detailed architecture,
including mechanisms like bitcoin scripts, transactions and L2 protocols,
and then derives claims from that base?
On Tue, May 23, 2023, 5:59 AM Burak Keceli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230523/0870c6d9/attachment.html>;
G. Andrew Stone [ARCHIVE] /
npub1ts…9cyxz
2023-06-07 23:21:52
in reply to nevent1q…evwm
Author Public Key
npub1tsl0vdp4gegx6p7m073lphfl7zcrctud0qhutzf63up2h6r2kdcq99cyxzPublished at
2023-06-07 23:21:52Event JSON
{
"id": "66170e8654d729832cdb69c5362997373bef4f7212e002f958d9db35305fb640",
"pubkey": "5c3ef6343546506d07db7fa3f0dd3ff0b03c2f8d782fc5893a8f02abe86ab370",
"created_at": 1686180112,
"kind": 1,
"tags": [
[
"e",
"e32c7f103abd16fde90ee98ca26651bd467d7c8d2ac01ef385cc5a044f4c88f6",
"",
"root"
],
[
"e",
"6ebc325508a53be44e40b84e446b55401786196d7cd62edfd3d74dbe3ebe6f46",
"",
"reply"
],
[
"p",
"8e87b0e46f5c041398cb59050eabcb90d868e9a35879843e95aec07c1bf7ee9d"
]
],
"content": "📅 Original date posted:2023-05-23\n🗒️ Summary of this message: A discussion on the potential risks of using Lightning Network and Atomic Swap Protocol (ASP) for Bitcoin transactions without waiting for on-chain confirmations.\n📝 Original message:Do you have any write up that presents a fully detailed architecture,\nincluding mechanisms like bitcoin scripts, transactions and L2 protocols,\nand then derives claims from that base?\n\nOn Tue, May 23, 2023, 5:59 AM Burak Keceli via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e As the access to Lightning is also by the (same?) ASP, it seems to me\n\u003e that the ASP will simply fail to forward the payment on the broader\n\u003e Lightning network after it has replaced the in-mempool transaction,\n\u003e preventing recipients from actually being able to rely on any received\n\u003e funds existing until the next pool transaction is confirmed.\n\u003e\n\u003e Yes, that's correct. Lightning payments are routed through ASPs. ASP may\n\u003e not cooperate in forwarding HTLC(s) AFTER double-spending their pool\n\u003e transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE\n\u003e double-spending their pool transaction.\n\u003e\n\u003e What makes Ark magical is, in the collaborative case, users' ability to\n\u003e pay lightning invoices with their zero-conf vTXOs, without waiting for\n\u003e on-chain confirmations.\n\u003e\n\u003e This is the opposite of swap-ins, where users SHOULD wait for on-chain\n\u003e confirmations before revealing their preimage of the HODL invoice;\n\u003e otherwise, the swap service provider can steal users' sats by\n\u003e double-spending their zero-conf HTLC.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230523/0870c6d9/attachment.html\u003e",
"sig": "a504433e6a621e58b63d595d6ded854658e9aae20da96e308795345a012d61b6c12a2220155cc815356456df5fc3998ddfba7e55735061ab5186cf23668632f3"
}