Here is an old write-up that should be read by everyone trying to design a NON-custodial L2: https://zmnscpxj.github.io/offchain/safety.html
Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, May 24th, 2023 at 12:40 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning Burak, > > > > 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. > > > This is why competent coders test their code for footguns before deploying in > production. > > > 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. > > > 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. > Again the LSP can also steal the funds by double-spending the 0-conf channel > open, like in the Ark case. > > The difference here is that once confirmed, the LSP can no longer attack you. > As I understand Ark, there is always an unconfirmed transaction that can be > double-spent by the ASP, so that the ASP can attack at any time. > > > 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. > > > If by "swap-in" you mean "onchain-to-offchain swap" then it is the user who > can double-spend their onchain 0-conf HTLC, not the swap service provider. > As the context is receiving money and then sending it out, I think that is > what you mean, but I think you also misunderstand the concept. > > Regards, > ZmnSPCxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
