From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2B2AAC0032; Fri, 20 Oct 2023 21:05:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 00C5641E5C; Fri, 20 Oct 2023 21:05:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 00C5641E5C Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=mattcorallo.com header.i=@mattcorallo.com header.a=rsa-sha256 header.s=1697834462 header.b=P+4BnGlh; dkim=pass (2048-bit key) header.d=clients.mail.as397444.net header.i=@clients.mail.as397444.net header.a=rsa-sha256 header.s=1697834465 header.b=S16zlg9I X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lArZzUssu2pX; Fri, 20 Oct 2023 21:05:57 +0000 (UTC) Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by smtp4.osuosl.org (Postfix) with ESMTPS id 57D4B41E46; Fri, 20 Oct 2023 21:05:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 57D4B41E46 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mattcorallo.com; s=1697834462; h=In-Reply-To:From:References:Cc:To:Subject: From:Subject:To:Cc:Reply-To; bh=ZPxZvU/RF6DYWXLJPtlBd3jsejviEjnCBntjsFYgY+g=; b=P+4BnGlhXXHmWBcaVp9pupAQxfomAu4H+KGe70iOo0X9Euftp8cBYpv8Sqa2FEUqYlQ44QDofN9 Mi/ZfejffS+Lny5PTt67+bg70byZh7O3utrMzCmWD9SC5qInx4yKq9w0Q3X15ip1Zb7oE0QThuZeV M5pkVfoBGUW3x8ShGUvNvpu7i3bXkJqtWYBK/oNGZad6rbb6NgcilQQZ2Ls8RNaM5YDxtEZyTn0ZM e1owC/CRkkAtZmtAHYsBGKJUssPVQ9D+mC8gXwKEzLW5WKbO/036uFV5SIx+19Cin+Yy4pMxpgyuQ FH6wdbJ8PxE5IDigN8yjouG0Uar5V0xaPeWQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=clients.mail.as397444.net; s=1697834465; h=In-Reply-To:From:References:Cc: To:Subject:From:Subject:To:Cc:Reply-To; bh=ZPxZvU/RF6DYWXLJPtlBd3jsejviEjnCBntjsFYgY+g=; b=S16zlg9IHrt2iMusgffeZewURN 0gKisbbbJmMIgvOjAQbeR3Ow7fyI+BiWnCKkGNlBWMURItIZMOu7ILcsqB4FsrMOruedOPjTEnExM tFwN47WaA7rNtLcQDkem74bdxk2oFfn0pdiQaiut4h+F+GXlOBaDd+hJ0ckffQBEtF0Y0T/eEBQtu Z+DrPcygY0B7gE2IEeaBqE8u1SG93acM1mro50i4hdZmeO9aqOAjUqMwhIcDATkA78Rs2k1Idlzli xDSuhDqbu/BZBFY542qe/OR/TY+mTSO87ZzlVyp3IFNyPtZh5FTs0YUOcu4/WsZermfFZoojZtdb5 y14w/C8g==; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1qtwgr-001We6-2k; Fri, 20 Oct 2023 21:05:53 +0000 Message-ID: <1a84a36c-ec23-43b5-9a61-1aafdc188892@mattcorallo.com> Date: Fri, 20 Oct 2023 17:05:48 -0400 MIME-Version: 1.0 Content-Language: en-US To: Matt Morehouse , Bitcoin Protocol Discussion , Peter Todd References: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com> From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: security@ariard.me, "lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" 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: Fri, 20 Oct 2023 21:05:59 -0000 Sadly this only is really viable for pre-anchor channels. With anchor channels the attack can be performed by either side of the closure, as the HTLCs are now, at max, only signed SIGHASH_SINGLE|ANYONECANPAY, allowing you to add more inputs and perform this attack even as the broadcaster. I don't think its really viable to walk that change back to fix this, as it also fixed plenty of other issues with channel usability and important edge-cases. I'll highlight that fixing this issue on the lightning end isn't really the right approach generally - we're talking about a case where a lightning counterparty engineered a transaction broadcast ordering such that miners are *not* including the optimal set of transactions for fee revenue. Given such a scenario exists (and its not unrealistic to think someone might wish to engineer such a situation), the fix ultimately needs to lie with Bitcoin Core (or other parts of the mining stack). Now, fixing this in the Bitcoin Core stack is no trivial deal - the reason for this attack is to keep enough history to fix it Bitcoin Core would need unbounded memory. However, its not hard to imagine a simple external piece of software which monitors the mempool for transactions which were replaced out but which may be able to re-enter the mempool later with other replacements and store them on disk. From there, this software could optimize the revenue of block template selection, while also accidentally fixing this issue. Matt On 10/20/23 2:35 PM, Matt Morehouse via bitcoin-dev wrote: > I think if we apply this presigned fee multiplier idea to HTLC spends, > we can prevent replacement cycles from happening. > > We could modify HTLC scripts so that *both* parties can only spend the > HTLC via presigned second-stage transactions, and we can always sign > those with SIGHASH_ALL. This will prevent the attacker from adding > inputs to their presigned transaction, so (AFAICT) a replacement > cycling attack becomes impossible. > > The tradeoff is more bookkeeping and less fee granularity when > claiming HTLCs on chain. > > On Fri, Oct 20, 2023 at 11:04 AM Peter Todd via bitcoin-dev > wrote: >> >> On Fri, Oct 20, 2023 at 10:31:03AM +0000, Peter Todd via bitcoin-dev wrote: >>> As I have suggested before, the correct way to do pre-signed transactions is to >>> pre-sign enough *different* transactions to cover all reasonable needs for >>> bumping fees. Even if you just increase the fee by 2x each time, pre-signing 10 >>> different replacement transactions covers a fee range of 1024x. And you >>> obviously can improve on this by increasing the multiplier towards the end of >>> the range. >> >> To be clear, when I say "increasing the multiplier", I mean, starting with a >> smaller multiplier at the beginning of the range, and ending with a bigger one. >> >> Eg feebumping with fee increases pre-signed for something like: >> >> 1.1 >> 1.2 >> 1.4 >> 1.8 >> 2.6 >> 4.2 >> 7.4 >> >> etc. >> >> That would use most of the range for smaller bumps, as a %, with larger % bumps >> reserved for the end where our strategy is changing to something more >> "scorched-earth" >> >> And of course, applying this idea properly to commitment transactions will mean >> that the replacements may have HTLCs removed, when their value drops below the >> fees necessary to get those outputs mined. >> >> Note too that we can sign simultaneous variants of transactions that deduct the >> fees from different party's outputs. Eg Alice can give Bob the ability to >> broadcast higher and higher fee txs, taking the fees from Bob's output(s), and >> Bob can give Alice the same ability, taking the fees from Alice's output(s). I >> haven't thought through how this would work with musig. But you can certainly >> do that with plain old OP_CheckMultisig. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev