ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-23 🗒️ Summary of this message: A write-up on ...
📅 Original date posted:2023-05-23
🗒️ Summary of this message: A write-up on designing a non-custodial L2 should be read by everyone, emphasizing the importance of testing for footguns before deploying in production.
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
🗒️ Summary of this message: A write-up on designing a non-custodial L2 should be read by everyone, emphasizing the importance of testing for footguns before deploying in production.
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev