summaryrefslogtreecommitdiff
path: root/3a/65e95b60011a10541e295a94ebf89a90c7c56b
blob: b5d9073aecefcee8a769df4b4040624a86888020 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 860E8C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 May 2023 00:40:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5FCE384033
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 May 2023 00:40:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5FCE384033
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=brTebTsq
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 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,
 FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id SR0_soa0dnB6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 May 2023 00:40:53 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5452A83FF2
Received: from mail-4027.protonmail.ch (mail-4027.protonmail.ch [185.70.40.27])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 5452A83FF2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 May 2023 00:40:53 +0000 (UTC)
Date: Wed, 24 May 2023 00:40:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1684888850; x=1685148050;
 bh=QKrsN3i3z24aadoGNVLm3RMgXVx2GTHXsziOk2Vge3E=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=brTebTsqv9IgzQBf+bDuqbPp7gJVUJN1Mr7oxOv49/t4/1znSaWwxFyLiAYB6USTS
 FetjfflUhZOFRuudHzYyucd/5wVac2DKMo6bXroEnf2eAFw2nMFYmb6kaj9Fdoq1Z7
 tBqVpkOAy8PnZ2x10HVqBjTz2JRFyIcX5OkHT39KQQ2fQnQKqtY/XWFZk2UXM0ReeT
 vpIemwD5YkdSVS8PeqWkbT4SQfXjgS9euv3EtcuS3KPvzbnX7jOPJGVRfogHBEn8ly
 +F/JW4pPkE67ES8rWp4pjJwzEeWhizWGmiFPHHBXxzd3Jtg5vu6okxX8xFmRKihCHm
 TgfCy06Y7hQTA==
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2023 00:40:55 -0000

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