path: root/1a/5c4fc41baa9d50854745fd14a0a73fa47e3af1

Return-Path: <bastien.teinturier@acinq.fr>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C26F9C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 13:03:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 9B95081F04
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 13:03:20 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9B95081F04
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=acinq.fr header.i=@acinq.fr
 header.a=rsa-sha256 header.s=google header.b=gMH4A1Yk
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01]
 autolearn=unavailable autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id m2_N-IUwACFv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 13:03:19 +0000 (UTC)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [IPv6:2a00:1450:4864:20::22b])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 2AE6981F1B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 13:03:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2AE6981F1B
Received: by mail-lj1-x22b.google.com with SMTP id
 38308e7fff4ca-2c5056059e0so61197081fa.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 06:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq.fr; s=google; t=1697547797; x=1698152597;
 darn=lists.linuxfoundation.org; 
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=bBVoXNKetzmbdRgIQuXjaPlo+nj1G5UEqkwZ0FF5YK4=;
 b=gMH4A1YkdbyrGuZ+blXOUxlP2lMgS9ngZEC3wMEJ4RmYhDH0bGSIxzeOQuO2Vwz7ac
 mWQbOIrTfVl273iJwDnSVHqW+i9C35SS4cDOPLifnKblBnlcyUcbpR7E3miIrWoBWc+G
 a78Gwd0pNnWK7F9g7Ck4d3SW+2kRMyERhBLQDD+Z4oMAjBNyxc8ekXwHIVMKL+LakPET
 +xZZ9aLbossgn/x3h7FPOL5fNuWxK0P1gwY3arssXGYdO1v4VpD6Tn3TeMXt6wOt3uaJ
 WR1BpRHanRW1UqjMK5C0PWB3gISGN0rLU/9p1Pqs8XgpGw+9xhiylOYSzT+zZKwHlUeX
 bcCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697547797; x=1698152597;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=bBVoXNKetzmbdRgIQuXjaPlo+nj1G5UEqkwZ0FF5YK4=;
 b=dP4nm84NSWCIYVildDIBPqooeJQQDb2JzHc3ilvhJ2Mslpowy4jWqsWUVWiYZf26YA
 3S80s7vCHeI3pQs5mcUPnfMHEmc/Tn2DVGzi2YrMosUHBlKonUhOBfhBTSf6+QQJK/D0
 F/4YjitWvvfX0NRf6QAb+CBIIARYCeOBKBh4Ko1YF2Y3J1D5ZvHiNQmqeoSzkdbKdbIl
 ZztCjCLkAJnreC8KGErXM0UVuxpg/O55UXGwFF9OHoM+cGUOA5XqqMaHjpQkZ9yv5cXA
 w64jVxBWMWznSD/IE2zwrEnQzh7PZLoS6PG3ByqaMrU0dxUmlTYiy2ZDrkYZ0qi8aHW4
 AClw==
X-Gm-Message-State: AOJu0YzU52/1in1uIZu5ySli/h7gARoTdhsGJM1H7R18BsKcHeehZTDO
 QT4QwTvuftCkyDrR6YaOd5kfs3js3/yWQZltDrv/r8aKg2m43zXqYUk=
X-Google-Smtp-Source: AGHT+IH+Qx5bURYs0z6jQZ2nfl9ehAiLkZdMsjV2nQ/8dKr2a5y6qvllvOB081IjBmqu+i0E/+adLFP+6RCbbbMZ0Cc=
X-Received: by 2002:ac2:5f76:0:b0:503:1b83:e352 with SMTP id
 c22-20020ac25f76000000b005031b83e352mr1385413lfc.52.1697547796430; Tue, 17
 Oct 2023 06:03:16 -0700 (PDT)
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"
X-Mailman-Approved-At: Tue, 17 Oct 2023 13:11:07 +0000
Subject: [bitcoin-dev] Batch exchange withdrawal to lightning requires
	covenants
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: Tue, 17 Oct 2023 13:03:21 -0000

--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--