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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 66D44C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 00:45:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 2E88184049
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 00:45:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2E88184049
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=VxL+iFQ5
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.102
X-Spam-Level:
X-Spam-Status: No, score=-1.102 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, URI_NOVOWEL=0.5]
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 66g8JC8FFnKA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 00:45:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 26EAA84043
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by smtp1.osuosl.org (Postfix) with ESMTPS id 26EAA84043
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 00:45:54 +0000 (UTC)
Date: Wed, 24 May 2023 00:45:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1684889152; x=1685148352;
bh=TTZ/hjsUNq3L8sFeIMdlIOBJUEQpEKkBNlj2qHK/tNs=;
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=VxL+iFQ5BndVYDFTvpGh/gB8WJcqLKqA6PlzdDuumKfRAX8LilYZ12a9xZJ8X0dXM
Oar6POqO+yspIi5u7toZ1azk/g18Btg2cGznVEUJlm1D+3zD++ba0UF4WosDhHBUfT
nCzUT98HFCVP68w6qb5D9jnnN1O2ZbOUfbp9m5Qt0tJFSRtjFvZrJYdZYmtWXjnTf1
Z/Egrm3rL0YGoBIz5Y0mptwOadaiiYx8pNkIbEHe5v8hnEhJ3Hj1nY+bhAk7v9tuTR
MEWX4c9ZwbjxoaglSGuCQAje20cwydn3YnF8dzTWk+wnba2Yc96bQzWoF697oBVHbP
XpTcQxyYbuw2g==
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
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:45:55 -0000
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
|
