From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C26F9C0032 for ; 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 ; 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 ; 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 ; 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 ; 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 Date: Tue, 17 Oct 2023 15:03:05 +0200 Message-ID: To: Bitcoin Protocol Discussion , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 footpr= int possible).

I've come to the conclusion that this is only pos= sible 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 thi= s usecase to the list of
useful things we could do if we had covenants (= insert "wen APO?" meme).

The naive way of enabling lightni= ng withdrawals is to make the user
provide a lightning invoice that the = exchange pays over lightning. The
issue is that in most cases, this simp= ly 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 wi= thdraw funds from an exchange, we most
likely will end up with N separat= e splice transactions.

Hence the idea of batching those into a singl= e transaction. Since we
don't want to introduce any intermediate tra= nsaction, we must be able
to create one transaction that splices multipl= e channels at once. The
issue is that for each of these channels, we nee= d a signature from the
corresponding wallet user, because we're spen= ding 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 availabili= ty 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 `SIG= HASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current
funding ou= tput to create a new funding output with the expected amount.
This lets = users sign *before* knowing the final transaction, which the
exchange ca= n 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 o= utput (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 ex= changing signatures for a commitment
transaction that sends the funds ba= ck to their owners *before* signing
the parent funding/splice transactio= n. 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 abl= e to sign before creating the batch)
so we don't know the new `prevo= ut` we should spend from. I couldn't find
a clever way to work aroun= d that, and I don't think there is one (but
I would be happy to be w= rong).

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 sign= ature
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 h= aven't looked at other forms of covenants, but most of them likely
a= ddress this problem as well.

Cheers,
Bastien
--0000000000006569570607e9257b--