diff options
| -rw-r--r-- | 67/a73424a85b1543e453620c0d274ba3feb9aa48 | 626 |
1 files changed, 626 insertions, 0 deletions
diff --git a/67/a73424a85b1543e453620c0d274ba3feb9aa48 b/67/a73424a85b1543e453620c0d274ba3feb9aa48 new file mode 100644 index 000000000..2ea37d2dd --- /dev/null +++ b/67/a73424a85b1543e453620c0d274ba3feb9aa48 @@ -0,0 +1,626 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 24FC2C0032; + Thu, 19 Oct 2023 17:10:06 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id EEF0F6FC1B; + Thu, 19 Oct 2023 17:10:05 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EEF0F6FC1B +Authentication-Results: smtp3.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20230601 header.b=j3CLUNYe +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 smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id nSa0h7hHU1yZ; Thu, 19 Oct 2023 17:10:04 +0000 (UTC) +Received: from mail-il1-x136.google.com (mail-il1-x136.google.com + [IPv6:2607:f8b0:4864:20::136]) + by smtp3.osuosl.org (Postfix) with ESMTPS id C95CE610CD; + Thu, 19 Oct 2023 17:10:03 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C95CE610CD +Received: by mail-il1-x136.google.com with SMTP id + e9e14a558f8ab-352a1a0348fso31515775ab.1; + Thu, 19 Oct 2023 10:10:03 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1697735403; x=1698340203; + 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=TlvXaJeWAf+ohNW/kGljx2TOHF9El082WknT0f27ZAk=; + b=j3CLUNYe6oInJtqyZmnnKiNEUQluYZgeU8SZJVKOY7J+BeSEniOGFMHu5rZOJef5pL + A54xhnMeWuYMA/C6hHz3lJtmcTImgqrRkGDd9kPg1FFFdot59uoGBGXjMVwqpNDroXRR + zcB4lwnqfQh2TGVSfXzq7k5dofvyc0kVOllTuAt22xYwf32JyCCjbeaBidfW3xRW2aum + yR6HyNvObCWJyaO1z8tWfJ9UtfwD16ynLx6UkUmZTPuUHwQE54LXnAenYbJrVdss70xZ + IjIKYxIfb9XOOlPcIAYrCGY4AipdA2d/3YSDxIyRYxXsOjz1wTAfNLonhav0E2LVxtqt + DpMA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1697735403; x=1698340203; + 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=TlvXaJeWAf+ohNW/kGljx2TOHF9El082WknT0f27ZAk=; + b=sRCXbbB+C2+GoVUwqa386yFTuYlP+tbKrCbpHEJ+6U2Yb2oNSgNFCJZAndhFIdGuvU + Ylg37aTqtBJKkMZ8H3IJbWYrMUJ7NHwb1lr6u9vI8/Ln31TDyG2ttFd9jaARsKTQlaI+ + LJZtu5kXmATWuxGbDRgVlqS7GEmVA56yf+q/rYBt3P+XFkL3Y/R9M3QUat2sYieNXBds + C6bWN4+7zG8zA5eyLnkkXDcz2QRTshtFRtws8JtI0DGDG2q8AqyqJNPZnG8nqzKO+ZEi + DPBBDTUnhbofmtnFKGp5Er2orjM2MK/mBNycjelg1gPV/hXkrDCb/7qk3JTi2NKqp1MX + Pl4Q== +X-Gm-Message-State: AOJu0Yx36xiisk24DIjKPz85MwC2qEtlsCH9k/zHY6t4VX7p++gvzZxE + 79sXfiisqMrdmjYbn3GHf3LT2oNKCjte94vq+7eyGl1cW3mxSQ== +X-Google-Smtp-Source: AGHT+IGHk5dkk7RsEhBMtoCozZ1SqwnYdWD3GIEom2InnckaYkFavfTDciujwC+KPBIpT5LFV4aLG2rLZqCkWoHeJ9M= +X-Received: by 2002:a92:d90e:0:b0:34f:9f86:dd45 with SMTP id + s14-20020a92d90e000000b0034f9f86dd45mr2882079iln.3.1697735402534; Thu, 19 Oct + 2023 10:10:02 -0700 (PDT) +MIME-Version: 1.0 +References: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com> + <CALZpt+E+od+nejiZDeMfQ+qLNMc8UnU=G1YVsH+REut6+Jj-Bg@mail.gmail.com> + <CACdvm3OJsg2Br91aDL8=eACTW1WkdQcUSCvpWyniuEZf+qSAuA@mail.gmail.com> + <CALZpt+EwwQJo16_5tWVBz6xRZ-O0q7S+JCuJm9hwGMrrgsdRjw@mail.gmail.com> + <CACdvm3MRkTnz_S8YKvMQW8tWDb6Q3hJT5jfzsTLMLM7j+4awzQ@mail.gmail.com> +In-Reply-To: <CACdvm3MRkTnz_S8YKvMQW8tWDb6Q3hJT5jfzsTLMLM7j+4awzQ@mail.gmail.com> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Thu, 19 Oct 2023 18:09:51 +0100 +Message-ID: <CALZpt+GPm36gwMbE5Co5VRckEYnLC+T1QcAQM+eOEB4erjORLg@mail.gmail.com> +To: Bastien TEINTURIER <bastien@acinq.fr> +Content-Type: multipart/alternative; boundary="000000000000973b90060814d314" +X-Mailman-Approved-At: Thu, 19 Oct 2023 21:52:02 +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: Thu, 19 Oct 2023 17:10:06 -0000 + +--000000000000973b90060814d314 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Bastien, + +Thanks for your additional comments. + +> Yes, they can, and any user could also double-spend the batch using a +> commit tx spending from the previous funding output. Participants must +> expect that this may happen, that's what I mentioned previously that +> you cannot use 0-conf on that splice transaction. But apart from that, +> it acts as a regular splice: participants must watch for double-spends +> (as discussed in the previous messages) while waiting for confirmations. + +Understood better, it's like a regular splice where one participant might +be able to double-spend at any time with a previous commit tx. So yes, +usual liquidity griefing we're already aware of I think and where one +should wait for a few confirmations before using spawned channels. + +> I don't think this should use nVersion=3D3 and pay 0 fees. On the contrar= +y +> this is a "standard" transaction that should use a reasonable feerate +> and nVersion=3D2, that's why I don't think this comment applies. + +Under this model where the splice should be a "standard" nVersion=3D2 +transaction that is using a reasonable feerate for non-delayed broadcast, +yes my comment does not apply, agree here. + +However for a hypothetical future, where the picked up feerate of the batch +splicing isn't compelling enough in face of mempool spikes, interactivity +to re-generate a bumped RBF might not be an option. Sadly re-broadcasting +the batch splice tx package with a bumped CPFP, might be affected by my +concern if it is correct. To be verified. + +Best, +Antoine + +Le jeu. 19 oct. 2023 =C3=A0 08:35, Bastien TEINTURIER <bastien@acinq.fr> a +=C3=A9crit : + +> Hi Antoine, +> +> > If I'm correct, two users can cooperate maliciously against the batch +> > withdrawal transactions by re-signing a CPFP from 2-of-2 and +> > broadcasting the batch withdrawal as a higher-feerate package / high +> > fee package and then evicting out the CPFP. +> +> Yes, they can, and any user could also double-spend the batch using a +> commit tx spending from the previous funding output. Participants must +> expect that this may happen, that's what I mentioned previously that +> you cannot use 0-conf on that splice transaction. But apart from that, +> it acts as a regular splice: participants must watch for double-spends +> (as discussed in the previous messages) while waiting for confirmations. +> +> > If the batch withdrawal has been signed with 0-fee thanks to the +> > nversion=3D3 policy exemption, it will be evicted out of the mempool. +> > A variant of a replacement cycling attack. +> +> I don't think this should use nVersion=3D3 and pay 0 fees. On the contrar= +y +> this is a "standard" transaction that should use a reasonable feerate +> and nVersion=3D2, that's why I don't think this comment applies. +> +> Cheers, +> Bastien +> +> Le mer. 18 oct. 2023 =C3=A0 20:04, Antoine Riard <antoine.riard@gmail.com= +> a +> =C3=A9crit : +> +>> Hi Bastien, +>> +>> Thanks for the answer. +>> +>> If I understand correctly the protocol you're describing you're aiming t= +o +>> enable batched withdrawals where a list of users are being sent funds fr= +om +>> an exchange directly in a list of channel funding outputs ("splice-out")= +. +>> Those channels funding outputs are 2-of-2, between two lambda users or e= +.g +>> a lambda user and a LSP. +>> +>> If I'm correct, two users can cooperate maliciously against the batch +>> withdrawal transactions by re-signing a CPFP from 2-of-2 and broadcastin= +g +>> the batch withdrawal as a higher-feerate package / high fee package and +>> then evicting out the CPFP. +>> +>> If the batch withdrawal has been signed with 0-fee thanks to the +>> nversion=3D3 policy exemption, it will be evicted out of the mempool. A +>> variant of a replacement cycling attack. +>> +>> I think this more or less matches the test I'm pointing to you which is +>> on non-deployed package acceptance code: +>> +>> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43= +d72f1efcf +>> +>> Please correct me if I'm wrong or missing assumptions. Agree with you on +>> the assumptions that the exchange does not have an incentive to +>> double-spend its own withdrawal transactions, or if all the batched fund= +ing +>> outputs are shared with a LSP, malicious collusion is less plausible. +>> +>> Best, +>> Antoine +>> +>> Le mer. 18 oct. 2023 =C3=A0 15:35, Bastien TEINTURIER <bastien@acinq.fr>= + a +>> =C3=A9crit : +>> +>>> Hey Z-man, Antoine, +>>> +>>> Thank you for your feedback, responses inline. +>>> +>>> z-man: +>>> +>>> > Then if I participate in a batched splice, I can disrupt the batched +>>> > splice by broadcasting the old state and somehow convincing miners to +>>> > confirm it before the batched splice. +>>> +>>> Correct, I didn't mention it in my post but batched splices cannot use +>>> 0-conf, the transaction must be confirmed to remove the risk of double +>>> spends using commit txs associated with the previous funding tx. +>>> +>>> But interestingly, with the protocol I drafted, the LSP can finalize an= +d +>>> broadcast the batched splice transaction while users are offline. With = +a +>>> bit of luck, when the users reconnect, that transaction will already be +>>> confirmed so it will "feel 0-conf". +>>> +>>> Also, we need a mechanism like the one you describe when we detect that +>>> a splice transaction has been double-spent. But this isn't specific to +>>> batched transactions, 2-party splice transactions can also be double +>>> spent by either participant. So we need that mechanism anyway? The spec +>>> doesn't have a way of aborting a splice after exchanging signatures, bu= +t +>>> you can always do it as an RBF operation (which actually just does a +>>> completely different splice). This is what Greg mentioned in his answer= +. +>>> +>>> > part of the splice proposal is that while a channel is being spliced, +>>> > it should not be spliced again, which your proposal seems to violate. +>>> +>>> The spec doesn't require that, I'm not sure what made you think that. +>>> While a channel is being spliced, it can definitely be spliced again as +>>> an RBF attempt (this is actually a very important feature), which doubl= +e +>>> spends the other unconfirmed splice attempts. +>>> +>>> ariard: +>>> +>>> > 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 usua= +l +>>> > risk models. +>>> +>>> I'm not entirely sure why you're bringing this up in this context... +>>> I agree that we most likely cannot use RBF on those batched transaction= +s +>>> we will need to rely on CPFP and potentially package relay. But why is +>>> it different from non-multi-party transactions here? +>>> +>>> > See test here: +>>> > +>>> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f4= +3d72f1efcf +>>> +>>> I'd argue that this is quite different from the standard replacement +>>> cycling attack, because in this protocol wallet users can only +>>> unilaterally double-spend with a commit tx, on which they cannot set +>>> the feerate. The only participant that can "easily" double-spend is +>>> the exchange, and they wouldn't have an incentive to here, users are +>>> only withdrawing funds, there's no opportunity of stealing funds? +>>> +>>> Thanks, +>>> Bastien +>>> +>>> Le mar. 17 oct. 2023 =C3=A0 21:10, Antoine Riard <antoine.riard@gmail.c= +om> a +>>> =C3=A9crit : +>>> +>>>> Hi Bastien, +>>>> +>>>> > The naive way of enabling lightning withdrawals is to make the user +>>>> > provide a lightning invoice that the exchange pays over lightning. T= +he +>>>> > 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 transactio= +n +>>>> > will be necessary. If N users withdraw funds from an exchange, we mo= +st +>>>> > 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/19d61fa8cf22a5050b51c4005603f= +43d72f1efcf +>>>> +>>>> 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.f= +r> a +>>>> =C3=A9crit : +>>>> +>>>>> Good morning list, +>>>>> +>>>>> I've been trying to design a protocol to let users withdraw funds fro= +m +>>>>> 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). T= +he +>>>>> 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. Th= +e +>>>>> 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 mos= +t +>>>>> 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 th= +e +>>>>> 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 ne= +ed +>>>>> signatures from N users who may not be online at the same time, and i= +f +>>>>> one of those users never comes online or doesn't complete the protoco= +l, +>>>>> we must discard the whole batch. +>>>>> +>>>>> There is a workaround though: each wallet user can provide a signatur= +e +>>>>> using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their curre= +nt +>>>>> funding output to create a new funding output with the expected amoun= +t. +>>>>> This lets users sign *before* knowing the final transaction, which th= +e +>>>>> 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 t= +he +>>>>> 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 commitme= +nt +>>>>> transaction that sends the funds back to their owners *before* signin= +g +>>>>> 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 b= +e +>>>>> valid to spend from the batch transaction. We are safe from signature +>>>>> reuse, because funding keys are rotated at each splice so we will nev= +er +>>>>> 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 +>>>>> +>>>> + +--000000000000973b90060814d314 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Bastien,<div><br></div><div>Thanks for your additional = +comments.</div><div><br></div><div>> Yes, they can, and any user could a= +lso double-spend the batch using a<br>> commit tx spending from the prev= +ious funding output. Participants must<br>> expect that this may happen,= + that's what I mentioned previously that<br>> you cannot use 0-conf = +on that splice transaction. But apart from that,<br>> it acts as a regul= +ar splice: participants must watch for double-spends<br>> (as discussed = +in the previous messages) while waiting for confirmations.<br></div><div><b= +r></div><div>Understood better, it's like a regular splice where one pa= +rticipant might be able to double-spend at any time with a previous commit = +tx. So yes, usual liquidity griefing we're already aware of I think and= + where one should wait for a few confirmations before using spawned channel= +s.</div><div><br></div><div>> I don't think this should use nVersion= +=3D3 and pay 0 fees. On the contrary<br>> this is a "standard"= + transaction that should use a reasonable feerate<br>> and nVersion=3D2,= + that's why I don't think this comment applies.<br></div><div><br><= +/div><div>Under this model where the splice should be a "standard"= +; nVersion=3D2 transaction that is using a reasonable feerate for non-delay= +ed broadcast, yes my comment does not apply, agree here.</div><div><br></di= +v><div>However for a hypothetical=C2=A0future, where the picked up feerate = +of the batch splicing isn't compelling enough in face of mempool spikes= +, interactivity to re-generate a bumped RBF might not be an option. Sadly r= +e-broadcasting the batch splice tx package with a bumped CPFP, might be aff= +ected by my concern if it is correct. To be verified.</div><div><br></div><= +div>Best,</div><div>Antoine</div></div><br><div class=3D"gmail_quote"><div = +dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 19 oct. 2023 =C3=A0=C2=A008:3= +5, Bastien TEINTURIER <<a href=3D"mailto:bastien@acinq.fr">bastien@acinq= +.fr</a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" = +style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s= +olid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">= +Hi Antoine,<br><br>> If I'm correct, two users can cooperate malicio= +usly against the batch<br>> withdrawal transactions by re-signing a CPFP= + from 2-of-2 and<br>> broadcasting the batch withdrawal as a higher-feer= +ate package / high<br>> fee package and then evicting out the CPFP.<br><= +br>Yes, they can, and any user could also double-spend the batch using a<br= +>commit tx spending from the previous funding output. Participants must<br>= +expect that this may happen, that's what I mentioned previously that<br= +>you cannot use 0-conf on that splice transaction. But apart from that,<br>= +it acts as a regular splice: participants must watch for double-spends<br>(= +as discussed in the previous messages) while waiting for confirmations.<br>= +<br>> If the batch withdrawal has been signed with 0-fee thanks to the<b= +r>> nversion=3D3 policy exemption, it will be evicted out of the mempool= +.<br>> A variant of a replacement cycling attack.<br><br>I don't thi= +nk this should use nVersion=3D3 and pay 0 fees. On the contrary<br>this is = +a "standard" transaction that should use a reasonable feerate<br>= +and nVersion=3D2, that's why I don't think this comment applies.<br= +><br>Cheers,<br>Bastien<br></div><br><div class=3D"gmail_quote"><div dir=3D= +"ltr" class=3D"gmail_attr">Le=C2=A0mer. 18 oct. 2023 =C3=A0=C2=A020:04, Ant= +oine Riard <<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_blank"= +>antoine.riard@gmail.com</a>> a =C3=A9crit=C2=A0:<br></div><blockquote c= +lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p= +x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1= +ex"><div dir=3D"ltr">Hi Bastien,<div><br></div><div>Thanks for the answer.<= +/div><div><br></div><div>If I understand correctly the protocol=C2=A0you= +9;re describing=C2=A0you're aiming to enable batched withdrawals where = +a list of users are being sent funds from an exchange directly in a list of= + channel funding outputs ("splice-out"). Those channels funding o= +utputs are 2-of-2, between two lambda users or e.g a lambda user and a LSP.= +</div><div><br></div><div>If I'm correct, two users can cooperate malic= +iously against the batch withdrawal transactions by re-signing a CPFP from = +2-of-2 and broadcasting the batch withdrawal as a higher-feerate package / = +high fee package and then evicting out the CPFP.=C2=A0</div><div><br></div>= +<div>If the batch withdrawal has been signed with 0-fee thanks to the nvers= +ion=3D3 policy exemption, it will be evicted out of the=C2=A0mempool. A var= +iant of a replacement cycling attack.</div><div><br></div><div>I think this= + more or less=C2=A0matches the test I'm pointing to you which is on non= +-deployed package acceptance code:</div><div><a href=3D"https://github.com/= +ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf" target=3D"_= +blank">https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c400560= +3f43d72f1efcf</a><br></div><div><br></div><div>Please correct me if I'm= + wrong or missing assumptions. Agree with you on the assumptions that the e= +xchange does not have an incentive to double-spend its own withdrawal trans= +actions, or if all the batched funding outputs are shared with a LSP, malic= +ious collusion is less plausible.</div><div><br></div><div>Best,</div><div>= +Antoine</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D= +"gmail_attr">Le=C2=A0mer. 18 oct. 2023 =C3=A0=C2=A015:35, Bastien TEINTURIE= +R <<a href=3D"mailto:bastien@acinq.fr" target=3D"_blank">bastien@acinq.f= +r</a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" st= +yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol= +id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">He= +y Z-man, Antoine,<br><br>Thank you for your feedback, responses inline.<br>= +<br>z-man:<br><br>> Then if I participate in a batched splice, I can dis= +rupt the batched<br>> splice by broadcasting the old state and somehow c= +onvincing miners to<br>> confirm it before the batched splice.<br><br>Co= +rrect, I didn't mention it in my post but batched splices cannot use<br= +>0-conf, the transaction must be confirmed to remove the risk of double<br>= +spends using commit txs associated with the previous funding tx.<br><br>But= + interestingly, with the protocol I drafted, the LSP can finalize and<br>br= +oadcast the batched splice transaction while users are offline. With a<br>b= +it of luck, when the users reconnect, that transaction will already be<br>c= +onfirmed so it will "feel 0-conf".<br><br>Also, we need a mechani= +sm like the one you describe when we detect that<br>a splice transaction ha= +s been double-spent. But this isn't specific to<br>batched transactions= +, 2-party splice transactions can also be double<br>spent by either partici= +pant. So we need that mechanism anyway? The spec<br>doesn't have a way = +of aborting a splice after exchanging signatures, but<br>you can always do = +it as an RBF operation (which actually just does a<br>completely different = +splice). This is what Greg mentioned in his answer.<br><br>> part of the= + splice proposal is that while a channel is being spliced,<br>> it shoul= +d not be spliced again, which your proposal seems to violate.<br><br>The sp= +ec doesn't require that, I'm not sure what made you think that.<br>= +While a channel is being spliced, it can definitely be spliced again as<br>= +an RBF attempt (this is actually a very important feature), which double<br= +>spends the other unconfirmed splice attempts.<br><br>ariard:<br><br>> I= +t is uncertain to me if secure fee-bumping, even with future<br>> mechan= +isms like package relay and nversion=3D3, is robust enough for<br>> mult= +i-party transactions and covenant-enable constructions under usual<br>> = +risk models.<br><br>I'm not entirely sure why you're bringing this = +up in this context...<br>I agree that we most likely cannot use RBF on thos= +e batched transactions<br>we will need to rely on CPFP and potentially pack= +age relay. But why is<br>it different from non-multi-party transactions her= +e?<br><br>> See test here:<br>> <a href=3D"https://github.com/ariard/= +bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf" target=3D"_blank">= +https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72= +f1efcf</a><br><br>I'd argue that this is quite different from the stand= +ard replacement<br>cycling attack, because in this protocol wallet users ca= +n only<br>unilaterally double-spend with a commit tx, on which they cannot = +set<br>the feerate. The only participant that can "easily" double= +-spend is<br>the exchange, and they wouldn't have an incentive to here,= + users are<br>only withdrawing funds, there's no opportunity of stealin= +g funds?<br><br>Thanks,<br>Bastien<br></div><br><div class=3D"gmail_quote">= +<div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2= +=A021:10, Antoine Riard <<a href=3D"mailto:antoine.riard@gmail.com" targ= +et=3D"_blank">antoine.riard@gmail.com</a>> a =C3=A9crit=C2=A0:<br></div>= +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= +left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p= +adding-left:1ex"><div dir=3D"ltr">Hi Bastien,<div><br></div><div>> The n= +aive way of enabling lightning withdrawals is to make the user<br>> prov= +ide 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's wallet provider: if the user do= +esn't<br>> have enough inbound liquidity (which is likely), a splice= + transaction<br>> will be necessary. If N users withdraw funds from an e= +xchange, we most<br>> likely will end up with N separate splice transact= +ions.<br></div><div><br></div><div>It is uncertain to me if secure fee-bump= +ing, even with future mechanisms like package relay and=C2=A0nversion=3D3, = +is robust enough for multi-party transactions and covenant-enable construct= +ions under usual risk models.</div><div><br></div><div>See test here:</div>= +<div><a href=3D"https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b= +51c4005603f43d72f1efcf" target=3D"_blank">https://github.com/ariard/bitcoin= +/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf</a><br></div><div><br></di= +v><div>Appreciated expert eyes of folks understanding both lightning and co= +re 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 o= +f the 3 Oct 2023.</div><div><br></div><div>Best,</div><div>Antoine</div></d= +iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le= +=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A014:03, Bastien TEINTURIER <<a href= +=3D"mailto:bastien@acinq.fr" target=3D"_blank">bastien@acinq.fr</a>> a = +=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= +n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le= +ft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Good morning l= +ist,<br><br>I've been trying to design a protocol to let users withdraw= + funds from<br>exchanges directly into their lightning wallet in an efficie= +nt way<br>(with the smallest on-chain footprint possible).<br><br>I've = +come to the conclusion that this is only possible with some form of<br>cove= +nants (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>use= +ful things we could do if we had covenants (insert "wen APO?" mem= +e).<br><br>The naive way of enabling lightning withdrawals is to make the u= +ser<br>provide a lightning invoice that the exchange pays over lightning. T= +he<br>issue is that in most cases, this simply shifts the burden of making = +an<br>on-chain transaction to the user's wallet provider: if the user d= +oesn't<br>have enough inbound liquidity (which is likely), a splice tra= +nsaction<br>will be necessary. If N users withdraw funds from an exchange, = +we most<br>likely will end up with N separate splice transactions.<br><br>H= +ence 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>issu= +e is that for each of these channels, we need a signature from the<br>corre= +sponding wallet user, because we're spending the current funding<br>out= +put, which is a 2-of-2 multisig between the wallet user and the<br>wallet p= +rovider. So we run into the usual availability problem: we need<br>signatur= +es from N users who may not be online at the same time, and if<br>one of th= +ose users never comes online or doesn't complete the protocol,<br>we mu= +st discard the whole batch.<br><br>There is a workaround though: each walle= +t user can provide a signature<br>using `SIGHASH_SINGLE | SIGHASH_ANYONECAN= +PAY` that spends their current<br>funding output to create a new funding ou= +tput with the expected amount.<br>This lets users sign *before* knowing the= + final transaction, which the<br>exchange can create by batching pairs of i= +nputs/outputs. But this has<br>a fatal issue: at that point 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). 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 exchanging signatures for a commi= +tment<br>transaction that sends the funds back to their owners *before* sig= +ning<br>the parent funding/splice transaction. But here that is impossible,= +<br>because we don't know yet the `txid` of the batch transaction (that= +'s<br>the whole point, we want to be able to sign before creating the b= +atch)<br>so we don't know the new `prevout` we should spend from. I cou= +ldn't find<br>a clever way to work around that, and I don't think t= +here is one (but<br>I would be happy to be wrong).<br><br>With `SIGHASH_ANY= +PREVOUT`, this is immediately fixed: we can exchange<br>anyprevout signatur= +es for the commitment transaction, and they will be<br>valid to spend from = +the batch transaction. We are safe from signature<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 haven't looked at other form= +s of covenants, but most of them likely<br>address this problem 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> +</blockquote></div> +</blockquote></div> +</blockquote></div> +</blockquote></div> + +--000000000000973b90060814d314-- + |