Date: Wed, 24 May 2023 00:40:42 +0000
To: Burak Keceli <burak@buraks.blog>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <RqMGBWFiZaAWDLpHiElcCqoOINqnqO_QfmBEYHfV0zkCJhQkhkwxaboCnRF6_2xU8tcVFcnpKzzXRhu126dKvAlsUUg_tx9KUTFZFb4mM5s=@protonmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
	Layer Solution
Precedence: list

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