From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A56C8C002A for ; Tue, 23 May 2023 22:06:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 7893B41DB5 for ; Tue, 23 May 2023 22:06:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7893B41DB5 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=hY+gjioe X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfZONRUNVbm5 for ; Tue, 23 May 2023 22:06:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 801D44023B Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by smtp2.osuosl.org (Postfix) with ESMTPS id 801D44023B for ; Tue, 23 May 2023 22:06:14 +0000 (UTC) Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2537909d28cso193941a91.0 for ; Tue, 23 May 2023 15:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684879574; x=1687471574; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=HdvCuvfVFzHnkXoeh1YfrcwHYs330FoNJzIlPrOcmnw=; b=hY+gjioe1myJNLRdM9WxH2HpMypeGXPBR/+6H/42kH5/if6z8RRb0ODM2tDDttCIFZ DiGjps3iEPhsHCddtXp/9ZEsOQmbmDgo0PsSX7xa3ZAGM4DYQ1K7DIAR+IQPac6IasgZ cabN9tGSvNWRA/I6kIWXWa3JulzNmqWlpDZKBB0SJav95bt2dC5Cqojr1NJEbx5yNRvB 5l9B4yzveHSDIGljsXeJ0h3ybnXej6/yaQW1XG8s04+RBaAtLhpEGelMmPpSgIB6sCUv J8bMHC2AE4vlB5z3eHXcQGVRV4Ss7ThJOg0QwTX2BtpWwxsTvGagR4smzndrEvXcvRZH eHpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684879574; x=1687471574; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HdvCuvfVFzHnkXoeh1YfrcwHYs330FoNJzIlPrOcmnw=; b=fMkkwjHW5HtpjYKt9T+L0Bi/nIFQcaejrj6qOEl4Y2O6PlVS4MkB2+A32m0pRsSxVd GTHJ4dn9f9EDANyjClH3htVSh+KOiF/zfd1pTDnqiTL+Z+pnA5YGwIFrbdg9r4U/ZcXO hc3sHebB7CQcctWZ3B2/ovIQ6J6g1wg6/O+lhMcP9j3dwvgg5BWBQeDELnhskv+w41Mt Vqku7FISyUAIo6oKzPnYmi3EYmsQgelbLC1Z823BZiZbfqDe1l6DXWwQeziYxerSHamE XzxiQo2wTtsagdELec8ZBqMOmpJz/bL/U91FQljmbN70/AqkQs2tIDLGwPulByTqs2Aw NSfQ== X-Gm-Message-State: AC+VfDz4LDN21ylXg48JBYAFkO+xURRcuw39ICMB7jgkEM3ff8qkfkXo c1DgvYhrFT7zHSI1pwOghm31L/thKgLJsthFyvTFX0cV X-Google-Smtp-Source: ACHHUZ5Z+oA5tmIX4U2fUP3BUuVn7XoeYu9nWecHtlygPtAlF/kbvqB+BiSmLKus/AEthZMOfhdus+FdV9FlBZ+udu0= X-Received: by 2002:a17:90a:928a:b0:23a:ad68:25a7 with SMTP id n10-20020a17090a928a00b0023aad6825a7mr14995538pjo.2.1684879573618; Tue, 23 May 2023 15:06:13 -0700 (PDT) MIME-Version: 1.0 References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com> <94d_XdPjU7_erTbusSTbsSWNNL3Wgx61scF_EknkwXp_ywmCLJ5jc13RVlTF_gpdZG5scUU_4z27qPykXQjLESE1m06CEJbsCha13QdqeFY=@protonmail.com> <2021501773.1219513.1684816284977@eu1.myprofessionalmail.com> In-Reply-To: <2021501773.1219513.1684816284977@eu1.myprofessionalmail.com> From: "G. Andrew Stone" Date: Tue, 23 May 2023 18:06:02 -0400 Message-ID: To: Burak Keceli , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000007992c705fc6398e3" 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: Tue, 23 May 2023 22:06:15 -0000 --0000000000007992c705fc6398e3 Content-Type: text/plain; charset="UTF-8" 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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000007992c705fc6398e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you have any write up that presents a fully detailed a= rchitecture, 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@lists.linuxfoundation.org> wrote:
> As the access to Lightning is a= lso by the (same?) ASP, it seems to me that the ASP will simply fail to for= ward 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 conf= irmed.

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-= 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 conf= irmations before revealing their preimage of the HODL invoice; otherwise, t= he swap service provider can steal users' sats by double-spending their= zero-conf HTLC.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--0000000000007992c705fc6398e3--