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" <g.andrew.stone@gmail.com>
Date: Tue, 23 May 2023 18:06:02 -0400
Message-ID: <CAHUwRvvo-HE=dY00jErFMgAqq_jCS_hCna=eaAQPYLkGSEHYtA@mail.gmail.com>
To: Burak Keceli <burak@buraks.blog>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007992c705fc6398e3"
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
	Layer Solution
Precedence: list

--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

<div dir=3D"auto">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?</div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 23, 2023, 5:=
59 AM Burak Keceli via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">&gt; 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.<br>
<br>
Yes, that&#39;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&#39;s a footgun if ASP forwards HTLC(s) BEFORE double-=
spending their pool transaction. <br>
<br>
What makes Ark magical is, in the collaborative case, users&#39; ability to=
 pay lightning invoices with their zero-conf vTXOs, without waiting for on-=
chain confirmations. <br>
<br>
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&#39; sats by double-spending their=
 zero-conf HTLC.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000007992c705fc6398e3--