Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants

From: Antoine Riard <antoine.riard@gmail•com>
To: Bastien TEINTURIER <bastien@acinq•fr>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	"lightning-dev\\\\@lists.linuxfoundation.org"
	<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants
Date: Tue, 17 Oct 2023 20:10:40 +0100	[thread overview]
Message-ID: <CALZpt+E+od+nejiZDeMfQ+qLNMc8UnU=G1YVsH+REut6+Jj-Bg@mail.gmail.com> (raw)
In-Reply-To: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>

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

Hi Bastien,

> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user doesn't
> have enough inbound liquidity (which is likely), a splice transaction
> will be necessary. If N users withdraw funds from an exchange, we most
> likely will end up with N separate splice transactions.

It is uncertain to me if secure fee-bumping, even with future mechanisms
like package relay and nversion=3, is robust enough for multi-party
transactions and covenant-enable constructions under usual risk models.

See test here:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf

Appreciated expert eyes of folks understanding both lightning and core
mempool on this.
There was a lot of back and forth on nversion=3 design rules, though the
test is normally built on glozow top commit of the 3 Oct 2023.

Best,
Antoine

Le mar. 17 oct. 2023 à 14:03, Bastien TEINTURIER <bastien@acinq•fr> a
écrit :

> Good morning list,
>
> I've been trying to design a protocol to let users withdraw funds from
> exchanges directly into their lightning wallet in an efficient way
> (with the smallest on-chain footprint possible).
>
> I've come to the conclusion that this is only possible with some form of
> covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The
> goal of this post is to explain why, and add this usecase to the list of
> useful things we could do if we had covenants (insert "wen APO?" meme).
>
> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user doesn't
> have enough inbound liquidity (which is likely), a splice transaction
> will be necessary. If N users withdraw funds from an exchange, we most
> likely will end up with N separate splice transactions.
>
> Hence the idea of batching those into a single transaction. Since we
> don't want to introduce any intermediate transaction, we must be able
> to create one transaction that splices multiple channels at once. The
> issue is that for each of these channels, we need a signature from the
> corresponding wallet user, because we're spending the current funding
> output, which is a 2-of-2 multisig between the wallet user and the
> wallet provider. So we run into the usual availability problem: we need
> signatures from N users who may not be online at the same time, and if
> one of those users never comes online or doesn't complete the protocol,
> we must discard the whole batch.
>
> There is a workaround though: each wallet user can provide a signature
> using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current
> funding output to create a new funding output with the expected amount.
> This lets users sign *before* knowing the final transaction, which the
> exchange can create by batching pairs of inputs/outputs. But this has
> a fatal issue: at that point the wallet user has no way of spending the
> new funding output (since it is also a 2-of-2 between the wallet user
> and the wallet provider). The wallet provider can now blackmail the user
> and force them to pay to get their funds back.
>
> Lightning normally fixes this by exchanging signatures for a commitment
> transaction that sends the funds back to their owners *before* signing
> the parent funding/splice transaction. But here that is impossible,
> because we don't know yet the `txid` of the batch transaction (that's
> the whole point, we want to be able to sign before creating the batch)
> so we don't know the new `prevout` we should spend from. I couldn't find
> a clever way to work around that, and I don't think there is one (but
> I would be happy to be wrong).
>
> With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange
> anyprevout signatures for the commitment transaction, and they will be
> valid to spend from the batch transaction. We are safe from signature
> reuse, because funding keys are rotated at each splice so we will never
> create another output that uses the same 2-of-2 script.
>
> I haven't looked at other forms of covenants, but most of them likely
> address this problem as well.
>
> Cheers,
> Bastien
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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