path: root/da/0bbd8262524ada3c9edc348d73e9ea61c7c8b6

Return-Path: <antoine.riard@gmail.com>
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: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
In-Reply-To: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 17 Oct 2023 20:10:40 +0100
Message-ID: <CALZpt+E+od+nejiZDeMfQ+qLNMc8UnU=G1YVsH+REut6+Jj-Bg@mail.gmail.com>
To: Bastien TEINTURIER <bastien@acinq.fr>
Content-Type: multipart/alternative; boundary="000000000000f8452c0607ee477b"
X-Mailman-Approved-At: Wed, 18 Oct 2023 00:07:44 +0000
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
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 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 <bastien@acinq.fr> 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

<div dir=3D"ltr">Hi Bastien,<div><br></div><div>&gt; The naive way of enabl=
ing lightning withdrawals is to make the user<br>&gt; provide a lightning i=
nvoice that the exchange pays over lightning. The<br>&gt; issue is that in =
most cases, this simply shifts the burden of making an<br>&gt; on-chain tra=
nsaction to the user&#39;s wallet provider: if the user doesn&#39;t<br>&gt;=
 have enough inbound liquidity (which is likely), a splice transaction<br>&=
gt; will be necessary. If N users withdraw funds from an exchange, we most<=
br>&gt; likely will end up with N separate splice transactions.<br></div><d=
iv><br></div><div>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.</div><div><br></div><div>See test here:</div><div><a href=3D"h=
ttps://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f=
1efcf">https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c400560=
3f43d72f1efcf</a><br></div><div><br></div><div>Appreciated expert eyes of f=
olks understanding both lightning and core mempool on this.</div><div>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.</div><div><br></d=
iv><div>Best,</div><div>Antoine</div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A0=
14:03, Bastien TEINTURIER &lt;<a href=3D"mailto:bastien@acinq.fr">bastien@a=
cinq.fr</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr">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 wa=
llet in an efficient way<br>(with the smallest on-chain footprint possible)=
.<br><br>I&#39;ve come to the conclusion that this is only possible with so=
me 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 this 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 lightning withdrawal=
s 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 simply shifts the=
 burden of making an<br>on-chain transaction to the user&#39;s wallet provi=
der: if the user doesn&#39;t<br>have enough inbound liquidity (which is lik=
ely), a splice transaction<br>will be necessary. If N users withdraw funds =
from an exchange, we most<br>likely will end up with N separate splice tran=
sactions.<br><br>Hence the idea of batching those into a single transaction=
. Since we<br>don&#39;t want to introduce any intermediate transaction, we =
must be able<br>to create one transaction that splices multiple channels at=
 once. The<br>issue is that for each of these channels, we need a signature=
 from the<br>corresponding wallet user, because we&#39;re spending the curr=
ent funding<br>output, which is a 2-of-2 multisig between the wallet user a=
nd the<br>wallet provider. So we run into the usual availability problem: w=
e need<br>signatures from N users who may not be online at the same time, a=
nd 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 `SIGHASH_SINGLE |=
 SIGHASH_ANYONECANPAY` that spends their current<br>funding output to creat=
e a new funding output with the expected amount.<br>This lets users sign *b=
efore* knowing the final transaction, which the<br>exchange can create by b=
atching pairs of inputs/outputs. But this has<br>a fatal issue: at that poi=
nt the wallet user has no way of spending the<br>new funding output (since =
it is also a 2-of-2 between the wallet user<br>and the wallet provider). Th=
e wallet provider can now blackmail the user<br>and force them to pay to ge=
t their funds back.<br><br>Lightning normally fixes this by exchanging sign=
atures for a commitment<br>transaction that sends the funds back to their o=
wners *before* signing<br>the parent funding/splice transaction. But here t=
hat 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 able to sign bef=
ore creating the batch)<br>so we don&#39;t know the new `prevout` we should=
 spend from. I couldn&#39;t find<br>a clever way to work around that, and I=
 don&#39;t think there is one (but<br>I would be happy to be wrong).<br><br=
>With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange<br>a=
nyprevout signatures for the commitment transaction, and they will be<br>va=
lid to spend from the batch transaction. We are safe from signature<br>reus=
e, because funding keys are rotated at each splice so we will never<br>crea=
te another output that uses the same 2-of-2 script.<br><br>I haven&#39;t lo=
oked at other forms of covenants, but most of them likely<br>address this p=
roblem as well.<br><br>Cheers,<br>Bastien<br></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>

--000000000000f8452c0607ee477b--