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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Return-Path: <tom@commerceblock.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id E9246C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2022 16:50:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id D4CA160A79
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2022 16:50:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=commerceblock-com.20210112.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id jnGKtHFsuJCl
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2022 16:50:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
[IPv6:2a00:1450:4864:20::631])
by smtp3.osuosl.org (Postfix) with ESMTPS id 6220660810
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2022 16:50:08 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id yy13so9843250ejb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 04 Mar 2022 08:50:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=commerceblock-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:from:date:message-id:subject:to;
bh=BP+wqua1+yZnMJKN8R4AJTUIBvOGFJwcUfZg1AWlh4g=;
b=o6ExzJFpYVC6CF/shIV8tzun4vVbT7pfODGCyTCmn6zpOnGRYI0KD6ZRBgzsO1eeEw
TBJbqEwOdAEeqKnUrJ62RtAx05+Z53WGNG9MvsBNnHXRNLJNuZXZyxUPsniLlvcoB78i
SKuD7PoLjITIyxwXyrITkbNiI4uqFFwFbFQ9Rs/SsWWZvWt+0fEYjbYtSmF3jcrNz6b1
HAE+DlRvoMTo++5W2EdA+A6rb/k2XiFHELhbz5CAIjjsAGee4XeJ1X7zegdYwGR8NpmN
IsmN4coO7Sgmm3E8GuyvZB/AqTzuOcLd2Jv+h4FkPJKVPaGP/zY71usm6lJ5u+xdO/7j
BCEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=BP+wqua1+yZnMJKN8R4AJTUIBvOGFJwcUfZg1AWlh4g=;
b=rZh0otwx7RpeT3dqmsSVYmMN2R4hhmMCgpIeyTUSRl6Ie+wOq+cPu7JnWOzsYhWR0X
1ykgdo64g10vMFGOwj9UdUu18OA8YoZQXoi8TibWYUMD1TAMJyXnjInrl5Wplie8jvo0
eI/WnFpYuhIkzVNNaeK+47pvuNo2v6ZAEQF/XfQq/kBTqGkmAj9pDaASsmUvzL8iBVGe
IH97WGAKmmOJitoxK4kymP32H+0XAsXccgqp8OhR4z53m54pJSFR2L1Ae3zcZQxebuvT
jMQD9pzv2t7M53NFD+96Y4Polx0ojiYLMT5Xf9yuNo8qd2mjC4x/74Fn8C+KSQa4sEjl
OA6w==
X-Gm-Message-State: AOAM531VyzVgHyeKhrjI/Pvi5QXnO3MLjFfi6l4lqlSI4eVsgPfCNoBe
0qRdYdJtu/x/mDv4ZnqPdkggNK3HOlOg11PBjIMzWU132q/Zimg=
X-Google-Smtp-Source: ABdhPJxWFwQ3ONJJ2Y6dlU+pqDob94x8M1bHezU9bPr98FoqSMl7PnR2nENOWdB0Wy5OY/89uMo1FsTmaClxA5mA62A=
X-Received: by 2002:a17:907:c012:b0:6d8:ec50:ef9b with SMTP id
ss18-20020a170907c01200b006d8ec50ef9bmr11798356ejc.284.1646412606170; Fri, 04
Mar 2022 08:50:06 -0800 (PST)
MIME-Version: 1.0
From: Tom Trevethan <tom@commerceblock.com>
Date: Fri, 4 Mar 2022 16:49:55 +0000
Message-ID: <CAJvkSsczASUaW4raLrVS9=3s0qoLGGD6g0WmKpDoPcdcRxBgHQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008b81b205d9674e6e"
X-Mailman-Approved-At: Fri, 04 Mar 2022 16:57:54 +0000
Subject: [bitcoin-dev] LN/mercury integrations
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: Fri, 04 Mar 2022 16:50:10 -0000
--0000000000008b81b205d9674e6e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
A couple of features we are considering for the mercury statechain
wallet/service and would be good to get comments/feedback on.
1.
In the current setup (https://github.com/commerceblock/mercury), deposits
are free and permissionless (i.e. no authentication required to generate a
shared key deposit addresses) and the mercury server fee (as a fixed
percentage of the coin value) is collected in the withdrawal transaction as
a UTXO paid to a fixed, specified bitcoin address. This has the advantage
of making the deposit process low friction and user friendly, but has some
disadvantages:
The withdrawal transaction fee output is typically a small fraction of the
coin value and for the smallest coin values is close to the dust limit
(i.e. these outputs may not be spendable in a high tx fee environment).
The on-chain mercury fee explicitly labels all withdrawn coins as mercury
statechain withdrawals, which is a privacy concern for many users.
The alternative that mitigates these issues is to charge the fee up-front,
via a LN invoice, before the shared key deposit address is generated. In
this approach, a user would specify in the wallet that they wanted to
deposit a specific amount into a statecoin, and instead of performing a
shared key generation with the server, would request a LN invoice for the
withdrawal fee from the server, which would be returned to the wallet and
displayed to the user.
The user would then copy this invoice (by C&P or QR code) into a third
party LN wallet and pay the fee. A LN node running on the mercury server
back end would then verify that the payment had been made, and enable the
wallet to continue with the deposit keygen and deposit process. This coin
would be labeled as =E2=80=98fee paid=E2=80=99 by the wallet and server, an=
d not be subject
to an on-chain fee payment on withdrawal.
2.
Withdrawal directly into LN channel.
Currently the wallet can send the coin to any type of bitcoin address
(except Taproot - P2TR - which is a pending straightforward upgrade).
To create a dual funded channel (i.e. a channel where the counterparty
provides BTC in addition to the mercury user) the withdrawal transaction
process and co-signing with the server must support the handling of PSBTs.
In this case, the withdrawal step would involve the mercury wallet
co-signing (with the mercury server), a PSBT created by a LN wallet.
To enable this, the mercury wallet should be able to both create a PSBT on
the withdrawal page, and then co-sign it with the server, and then send it
to the channel counterparty out of band (or via the third party LN
wallet/node), and import a PSBT created by the channel counterparty and
sign it, and export and/or broadcast the fully signed PSBT.
This seems to be possible (i.e. paying directly to a dual funded channel
opening tx from a third party wallet) with c-lightning and lnd via RPC, but
I=E2=80=99m not aware of any LN wallet that would support this kind of thin=
g. It
has the potential to eliminate an on-chain tx, which could be valuable in a
high-fee environment.
--0000000000008b81b205d9674e6e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A couple of features we are considering for the mercury st=
atechain wallet/service and would be good to get comments/feedback on. <br>=
<br>1. <br>In the current setup (<a href=3D"https://github.com/commercebloc=
k/mercury">https://github.com/commerceblock/mercury</a>), deposits are free=
and permissionless (i.e. no authentication required to generate a shared k=
ey deposit addresses) and the mercury server fee (as a fixed percentage of =
the coin value) is collected in the withdrawal transaction as a UTXO paid t=
o a fixed, specified bitcoin address. This has the advantage of making the =
deposit process low friction and user friendly, but has some disadvantages:=
<br><br>The withdrawal transaction fee output is typically a small fraction=
of the coin value and for the smallest coin values is close to the dust li=
mit (i.e. these outputs may not be spendable in a high tx fee environment).=
<br>The on-chain mercury fee explicitly labels all withdrawn coins as merc=
ury statechain withdrawals, which is a privacy concern for many users. <br>=
<br>The alternative that mitigates these issues is to charge the fee up-fro=
nt, via a LN invoice, before the shared key deposit address is generated. I=
n this approach, a user would specify in the wallet that they wanted to dep=
osit a specific amount into a statecoin, and instead of performing a shared=
=C2=A0key generation with the server, would request a LN invoice for the w=
ithdrawal fee from the server, which would be returned to the wallet and di=
splayed to the user. <br><br>The user would then copy this invoice (by C&am=
p;P or QR code) into a third party LN wallet and pay the fee. A LN node run=
ning on the mercury server back end would then verify that the payment had =
been made, and enable the wallet to continue with the deposit keygen and de=
posit process. This coin would be labeled as =E2=80=98fee paid=E2=80=99 by =
the wallet and server, and not be subject to an on-chain fee payment on wit=
hdrawal. <br><br><br>2. <br>Withdrawal directly into LN channel. <br><br>Cu=
rrently the wallet can send the coin to any type of bitcoin address (except=
Taproot - P2TR - which is a pending straightforward upgrade). <br>To creat=
e a dual funded channel (i.e. a channel where the counterparty provides BTC=
in addition to the mercury user) the withdrawal transaction process and co=
-signing with the server must support the handling of PSBTs. In this case, =
the withdrawal step would involve the mercury wallet co-signing (with the m=
ercury server), a PSBT created by a LN wallet. <br><br>To enable this, the =
mercury wallet should be able to both create a PSBT on the withdrawal page,=
and then co-sign it with the server, and then send it to the channel count=
erparty out of band (or via the third party LN wallet/node), and import a P=
SBT created by the channel counterparty and sign it, and export and/or broa=
dcast the fully signed PSBT. <br><br>This seems to be possible (i.e. paying=
directly to a dual funded channel opening tx from a third party wallet) wi=
th c-lightning and lnd via RPC, but I=E2=80=99m not aware of any LN wallet =
that would support this kind of thing. It has the potential to eliminate an=
on-chain tx, which could be valuable in a high-fee environment.=C2=A0<br><=
/div>
--0000000000008b81b205d9674e6e--
|