From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 860E8C002A for ; Wed, 24 May 2023 00:40:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5FCE384033 for ; Wed, 24 May 2023 00:40:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5FCE384033 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=brTebTsq X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR0_soa0dnB6 for ; Wed, 24 May 2023 00:40:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5452A83FF2 Received: from mail-4027.protonmail.ch (mail-4027.protonmail.ch [185.70.40.27]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5452A83FF2 for ; Wed, 24 May 2023 00:40:53 +0000 (UTC) Date: Wed, 24 May 2023 00:40:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1684888850; x=1685148050; bh=QKrsN3i3z24aadoGNVLm3RMgXVx2GTHXsziOk2Vge3E=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=brTebTsqv9IgzQBf+bDuqbPp7gJVUJN1Mr7oxOv49/t4/1znSaWwxFyLiAYB6USTS FetjfflUhZOFRuudHzYyucd/5wVac2DKMo6bXroEnf2eAFw2nMFYmb6kaj9Fdoq1Z7 tBqVpkOAy8PnZ2x10HVqBjTz2JRFyIcX5OkHT39KQQ2fQnQKqtY/XWFZk2UXM0ReeT vpIemwD5YkdSVS8PeqWkbT4SQfXjgS9euv3EtcuS3KPvzbnX7jOPJGVRfogHBEn8ly +F/JW4pPkE67ES8rWp4pjJwzEeWhizWGmiFPHHBXxzd3Jtg5vu6okxX8xFmRKihCHm TgfCy06Y7hQTA== To: Burak Keceli From: ZmnSCPxj Message-ID: In-Reply-To: <2021501773.1219513.1684816284977@eu1.myprofessionalmail.com> References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com> <94d_XdPjU7_erTbusSTbsSWNNL3Wgx61scF_EknkwXp_ywmCLJ5jc13RVlTF_gpdZG5scUU_4z27qPykXQjLESE1m06CEJbsCha13QdqeFY=@protonmail.com> <2021501773.1219513.1684816284977@eu1.myprofessionalmail.com> Feedback-ID: 2872618:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2023 00:40:55 -0000 Good morning Burak, > > As the access to Lightning is also by the (same?) ASP, it seems to me t= hat the ASP will simply fail to forward the payment on the broader Lightnin= g network after it has replaced the in-mempool transaction, preventing reci= pients from actually being able to rely on any received funds existing unti= l the next pool transaction is confirmed. >=20 >=20 > Yes, that's correct. Lightning payments are routed through ASPs. ASP may = not cooperate in forwarding HTLC(s) AFTER double-spending their pool transa= ction. However, it's a footgun if ASP forwards HTLC(s) BEFORE double-spendi= ng 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 p= ay lightning invoices with their zero-conf vTXOs, without waiting for on-ch= ain 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 Li= ghtning again, without waiting for onchain confirmations. Again the LSP can also steal the funds by double-spending the 0-conf channe= l open, like in the Ark case. The difference here is that once confirmed, the LSP can no longer attack yo= u. 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 co= nfirmations before revealing their preimage of the HODL invoice; otherwise,= the swap service provider can steal users' sats by double-spending their z= ero-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