MIME-Version: 1.0
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Tue, 17 Oct 2023 15:03:05 +0200
Message-ID: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006569570607e9257b"
Subject: [bitcoin-dev] Batch exchange withdrawal to lightning requires
	covenants
Precedence: list

--0000000000006569570607e9257b
Content-Type: text/plain; charset="UTF-8"

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

--0000000000006569570607e9257b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Good morning list,<br><br>I&#39;ve been trying to design a=
 protocol to let users withdraw funds from<br>exchanges directly into their=
 lightning wallet in an efficient way<br>(with the smallest on-chain footpr=
int possible).<br><br>I&#39;ve come to the conclusion that this is only pos=
sible with some form of<br>covenants (e.g. `SIGHASH_ANYPREVOUT` would work =
fine in this case). The<br>goal of this post is to explain why, and add thi=
s usecase to the list of<br>useful things we could do if we had covenants (=
insert &quot;wen APO?&quot; meme).<br><br>The naive way of enabling lightni=
ng withdrawals is to make the user<br>provide a lightning invoice that the =
exchange pays over lightning. The<br>issue is that in most cases, this simp=
ly shifts the burden of making an<br>on-chain transaction to the user&#39;s=
 wallet provider: if the user doesn&#39;t<br>have enough inbound liquidity =
(which is likely), a splice transaction<br>will be necessary. If N users wi=
thdraw funds from an exchange, we most<br>likely will end up with N separat=
e splice transactions.<br><br>Hence the idea of batching those into a singl=
e transaction. Since we<br>don&#39;t want to introduce any intermediate tra=
nsaction, we must be able<br>to create one transaction that splices multipl=
e channels at once. The<br>issue is that for each of these channels, we nee=
d a signature from the<br>corresponding wallet user, because we&#39;re spen=
ding the current funding<br>output, which is a 2-of-2 multisig between the =
wallet user and the<br>wallet provider. So we run into the usual availabili=
ty problem: we need<br>signatures from N users who may not be online at the=
 same time, and if<br>one of those users never comes online or doesn&#39;t =
complete the protocol,<br>we must discard the whole batch.<br><br>There is =
a workaround though: each wallet user can provide a signature<br>using `SIG=
HASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current<br>funding ou=
tput to create a new funding output with the expected amount.<br>This lets =
users sign *before* knowing the final transaction, which the<br>exchange ca=
n create by batching pairs of inputs/outputs. But this has<br>a fatal issue=
: at that point the wallet user has no way of spending the<br>new funding o=
utput (since it is also a 2-of-2 between the wallet user<br>and the wallet =
provider). The wallet provider can now blackmail the user<br>and force them=
 to pay to get their funds back.<br><br>Lightning normally fixes this by ex=
changing signatures for a commitment<br>transaction that sends the funds ba=
ck to their owners *before* signing<br>the parent funding/splice transactio=
n. But here that is impossible,<br>because we don&#39;t know yet the `txid`=
 of the batch transaction (that&#39;s<br>the whole point, we want to be abl=
e to sign before creating the batch)<br>so we don&#39;t know the new `prevo=
ut` we should spend from. I couldn&#39;t find<br>a clever way to work aroun=
d that, and I don&#39;t think there is one (but<br>I would be happy to be w=
rong).<br><br>With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can =
exchange<br>anyprevout signatures for the commitment transaction, and they =
will be<br>valid to spend from the batch transaction. We are safe from sign=
ature<br>reuse, because funding keys are rotated at each splice so we will =
never<br>create another output that uses the same 2-of-2 script.<br><br>I h=
aven&#39;t looked at other forms of covenants, but most of them likely<br>a=
ddress this problem as well.<br><br>Cheers,<br>Bastien<br></div>

--0000000000006569570607e9257b--