summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Trevethan <tom@commerceblock.com>2022-03-04 16:49:55 +0000
committerbitcoindev <bitcoindev@gnusha.org>2022-03-04 16:50:09 +0000
commita86fa93b88ce22ef95b50e2ea6606ebb8a08ed7e (patch)
treec3dd7829024274570673ea3dee896519cebadf01
parent56c085e11fcda924735db0ee3696eac80a60f5c4 (diff)
downloadpi-bitcoindev-a86fa93b88ce22ef95b50e2ea6606ebb8a08ed7e.tar.gz
pi-bitcoindev-a86fa93b88ce22ef95b50e2ea6606ebb8a08ed7e.zip
[bitcoin-dev] LN/mercury integrations
Diffstat
-rw-r--r--91/e5665cff488a4dc27f5045db8ed05d5bb9a1fd195
1 files changed, 195 insertions, 0 deletions
diff --git a/91/e5665cff488a4dc27f5045db8ed05d5bb9a1fd b/91/e5665cff488a4dc27f5045db8ed05d5bb9a1fd
new file mode 100644
index 000000000..f422b6374
--- /dev/null
+++ b/91/e5665cff488a4dc27f5045db8ed05d5bb9a1fd
@@ -0,0 +1,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--
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-05-04 14:11:24 +0000