Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 66D44C002A for ; Wed, 24 May 2023 00:45:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2E88184049 for ; Wed, 24 May 2023 00:45:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2E88184049 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=VxL+iFQ5 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 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, URI_NOVOWEL=0.5] 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 66g8JC8FFnKA for ; Wed, 24 May 2023 00:45:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 26EAA84043 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by smtp1.osuosl.org (Postfix) with ESMTPS id 26EAA84043 for ; Wed, 24 May 2023 00:45:54 +0000 (UTC) Date: Wed, 24 May 2023 00:45:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1684889152; x=1685148352; bh=TTZ/hjsUNq3L8sFeIMdlIOBJUEQpEKkBNlj2qHK/tNs=; 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=VxL+iFQ5BndVYDFTvpGh/gB8WJcqLKqA6PlzdDuumKfRAX8LilYZ12a9xZJ8X0dXM Oar6POqO+yspIi5u7toZ1azk/g18Btg2cGznVEUJlm1D+3zD++ba0UF4WosDhHBUfT nCzUT98HFCVP68w6qb5D9jnnN1O2ZbOUfbp9m5Qt0tJFSRtjFvZrJYdZYmtWXjnTf1 Z/Egrm3rL0YGoBIz5Y0mptwOadaiiYx8pNkIbEHe5v8hnEhJ3Hj1nY+bhAk7v9tuTR MEWX4c9ZwbjxoaglSGuCQAje20cwydn3YnF8dzTWk+wnba2Yc96bQzWoF697oBVHbP XpTcQxyYbuw2g== To: ZmnSCPxj , Bitcoin Protocol Discussion From: ZmnSCPxj Message-ID: In-Reply-To: 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: Burak Keceli 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:45:55 -0000 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 wrote: > Good morning Burak, >=20 > > > 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 Lightn= ing network after it has replaced the in-mempool transaction, preventing re= cipients from actually being able to rely on any received funds existing un= til the next pool transaction is confirmed. > >=20 > > Yes, that's correct. Lightning payments are routed through ASPs. ASP ma= y not cooperate in forwarding HTLC(s) AFTER double-spending their pool tran= saction. However, it's a footgun if ASP forwards HTLC(s) BEFORE double-spen= ding their pool transaction. >=20 >=20 > This is why competent coders test their code for footguns before deployin= g in production. >=20 > > 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. >=20 >=20 > You can also do the same in Lightning, with the same risk profile: the LS= P 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 chan= nel open, like in the Ark case. >=20 > 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. >=20 > > This is the opposite of swap-ins, where users SHOULD wait for on-chain = confirmations before revealing their preimage of the HODL invoice; otherwis= e, the swap service provider can steal users' sats by double-spending their= zero-conf HTLC. >=20 >=20 > If by "swap-in" you mean "onchain-to-offchain swap" then it is the user w= ho can double-spend their onchain 0-conf HTLC, not the swap service provide= r. > As the context is receiving money and then sending it out, I think that i= s what you mean, but I think you also misunderstand the concept. >=20 > Regards, > ZmnSPCxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev