Date: Wed, 24 May 2023 00:45:49 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ApngTTvW46O8UkGVrWosWYbTPx5gBVUXL46ihSRkA1jVXNqxLtKXpA-unovlJHXFfAYxIPInJwg849K2MeDUymPqn8Mp_CeUMnK3UYiGmcQ=@protonmail.com>
In-Reply-To: <RqMGBWFiZaAWDLpHiElcCqoOINqnqO_QfmBEYHfV0zkCJhQkhkwxaboCnRF6_2xU8tcVFcnpKzzXRhu126dKvAlsUUg_tx9KUTFZFb4mM5s=@protonmail.com>
References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
 <94d_XdPjU7_erTbusSTbsSWNNL3Wgx61scF_EknkwXp_ywmCLJ5jc13RVlTF_gpdZG5scUU_4z27qPykXQjLESE1m06CEJbsCha13QdqeFY=@protonmail.com>
 <2021501773.1219513.1684816284977@eu1.myprofessionalmail.com>
 <RqMGBWFiZaAWDLpHiElcCqoOINqnqO_QfmBEYHfV0zkCJhQkhkwxaboCnRF6_2xU8tcVFcnpKzzXRhu126dKvAlsUUg_tx9KUTFZFb4mM5s=@protonmail.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 <burak@buraks.blog>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
	Layer Solution
Precedence: list

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 <bitcoin=
-dev@lists.linuxfoundation.org> 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