Date: Mon, 22 May 2023 13:03:00 +0000
To: Burak Keceli <burak@buraks.blog>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <94d_XdPjU7_erTbusSTbsSWNNL3Wgx61scF_EknkwXp_ywmCLJ5jc13RVlTF_gpdZG5scUU_4z27qPykXQjLESE1m06CEJbsCha13QdqeFY=@protonmail.com>
In-Reply-To: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
	Layer Solution
Precedence: list

Good morning Burak,

I have not gone through the deep dive fully yet, but I find myself confused=
 about this particular claim:

> A pool transaction can be double-spent by the Ark service provider while =
it remains in the mempool. However, in the meantime, the recipient can pay =
a lightning invoice with their incoming zero-conf vTXOs, so it=E2=80=99s a =
footgun for the service operator to double-spend in this case.=C2=A0

Given that you make this claim:

> ASPs on Ark are both (1) liquidity providers, (2) blinded coinjoin coordi=
nators, and (3) Lightning service providers. ASPs main job is to create rap=
id, blinded coinjoin sessions every five seconds, also known as pools.

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 ne=
twork after it has replaced the in-mempool transaction, preventing recipien=
ts from actually being able to rely on any received funds existing until th=
e next pool transaction is confirmed.

Even if the Lightning access is somehow different from the ASP you are rece=
iving funds on, one ASP cannot prove that another ASP is not its sockpuppet=
 except via some expensive process (i.e. locking funds or doing proof-of-wo=
rk).

Regards,
ZmnSCPxj