Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1462DC0032; Tue, 17 Oct 2023 19:10:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id DED208206A; Tue, 17 Oct 2023 19:10:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DED208206A Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=RIR1Zxuz X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 WSZ-tTpbKTRa; Tue, 17 Oct 2023 19:10:52 +0000 (UTC) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by smtp1.osuosl.org (Postfix) with ESMTPS id 603768200E; Tue, 17 Oct 2023 19:10:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 603768200E Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-3579ec224c9so1702185ab.1; Tue, 17 Oct 2023 12:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697569851; x=1698174651; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KxuGzBqde9qy4izFPYCnXx415v1zokN4Vl5zJ48uc6k=; b=RIR1Zxuz7zjG3TOXlt+jthleO+sC5Cp9+opcmAuxeUeyZLZtnHp1yhSU8inIVJtj9Z 4PRFG8YQNVynatP9T81X0ZecQhcd4ePUnai7QmP0v67VFxvbDYCh5IA9dzen6TqPMESm xpPS6vOAKLYey7kTogc6bsc/MOMfuJueXxtA7WVofbyRZoDcJLmwzq6j5i23KAAw6Wpy OL+ACW18hfMGTw+k7MkEuH6yBmfBDggRbADmFQzRm7rb8SYwMeODt2TCU4jNam13U/bO mEiLG2SUkeRImq8uVrhtzSqO8ttMdboY9nGSQ50dZWXUHLqU6WoiKHEfntfyVKsBwo// 8L1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697569851; x=1698174651; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KxuGzBqde9qy4izFPYCnXx415v1zokN4Vl5zJ48uc6k=; b=P9D8Tf80CqG6/tkc2eA1LHKl/oib80NFJj9Ng3Z1qwqDO4w5bnD4iBpMVlwI0qGnGj 8rtGxit7fB7Tr6qgHNHppg84ZbSfbFDw128ZNmw5SZYnvgz8pejRRwADPiKD4U8AHbln SdBZzxEMF+0APgNnQzFNV1Sy8TSj0uOwQ0sNZ5UjBJMgdJaIf3nKu/f0jC056jdcFjvG sUJnx1uXBX3rM5Td9LVI8WIjJZwOrIh7+Q/7kNN1pENq0gMhUHcDqddPQhDHk9HvjbbC ixKitHZw3H4j2S3af7nn5FIpXXWMUeoS4b/TtkZNLaMj071lCJx+jTHnUeIof5K7Q7C6 bNyw== X-Gm-Message-State: AOJu0YxkOPyw5msOciPhfk2dmSim0Yejyc8YtPokGPRv29Rx9D4W8WOI xvhce+kXVysu7k/na4u+Qcgzy2VR8wEYvQ8XQcl+I5HH3k+/vQ== X-Google-Smtp-Source: AGHT+IGLg55k+utWoRSVmvS7Q76NYZzIMFi37GITCj23IBULARojbMDraYEvoO6umwOr0aN8b2OYipknoiDraClU3Eg= X-Received: by 2002:a92:dcc3:0:b0:351:35d9:f18f with SMTP id b3-20020a92dcc3000000b0035135d9f18fmr2675733ilr.2.1697569851325; Tue, 17 Oct 2023 12:10:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Tue, 17 Oct 2023 20:10:40 +0100 Message-ID: To: Bastien TEINTURIER Content-Type: multipart/alternative; boundary="000000000000f8452c0607ee477b" X-Mailman-Approved-At: Wed, 18 Oct 2023 00:07:44 +0000 Cc: Bitcoin Protocol Discussion , "lightning-dev\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-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 19:10:54 -0000 --000000000000f8452c0607ee477b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3D3, is robust enough for multi-party transactions and covenant-enable constructions under usual risk models. See test here: https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72= f1efcf Appreciated expert eyes of folks understanding both lightning and core mempool on this. There was a lot of back and forth on nversion=3D3 design rules, though the test is normally built on glozow top commit of the 3 Oct 2023. Best, Antoine Le mar. 17 oct. 2023 =C3=A0 14:03, Bastien TEINTURIER a =C3=A9crit : > 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 > --000000000000f8452c0607ee477b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bastien,

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

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

See test here:

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

Best,
Antoine

<= div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A0= 14:03, Bastien TEINTURIER <bastien@a= cinq.fr> a =C3=A9crit=C2=A0:
Good morning list,

I've been trying to design a protocol to = let users withdraw funds from
exchanges directly into their lightning wa= llet in an efficient way
(with the smallest on-chain footprint possible)= .

I've come to the conclusion that this is only possible with so= me 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 withdrawal= s 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 provi= der: if the user doesn't
have enough inbound liquidity (which is lik= ely), a splice transaction
will be necessary. If N users withdraw funds = from an exchange, we most
likely will end up with N separate splice tran= sactions.

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 curr= ent funding
output, which is a 2-of-2 multisig between the wallet user a= nd the
wallet provider. So we run into the usual availability problem: w= e need
signatures from N users who may not be online at the same time, a= nd 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 creat= e a new funding output with the expected amount.
This lets users sign *b= efore* knowing the final transaction, which the
exchange can create by b= atching pairs of inputs/outputs. But this has
a fatal issue: at that poi= nt 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). Th= e wallet provider can now blackmail the user
and force them to pay to ge= t their funds back.

Lightning normally fixes this by exchanging sign= atures for a commitment
transaction that sends the funds back to their o= wners *before* signing
the parent funding/splice transaction. But here t= hat 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 bef= ore 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
a= nyprevout signatures for the commitment transaction, and they will be
va= lid to spend from the batch transaction. We are safe from signature
reus= e, because funding keys are rotated at each splice so we will never
crea= te another output that uses the same 2-of-2 script.

I haven't lo= oked at other forms of covenants, but most of them likely
address this p= roblem as well.

Cheers,
Bastien
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev
--000000000000f8452c0607ee477b--