[bitcoin-dev] LN/mercury integrations

[bitcoin-dev] LN/mercury integrations

[Tom Trevethan]

[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

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 ‘fee paid’ by the wallet and server, and 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’m 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.

[-- Attachment #2: Type: text/html, Size: 3202 bytes --]