From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 29 Jul 2024 22:48:27 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sYfik-0005HO-9P for bitcoindev@gnusha.org; Mon, 29 Jul 2024 22:48:27 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-260e8c635afsf4705585fac.0 for ; Mon, 29 Jul 2024 22:48:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1722318500; cv=pass; d=google.com; s=arc-20160816; b=Xc0CfAxVjkfnJxnTfAissIyLAwNXxsiR7ywaITGVFR/n0sysc6qoJkmYaXk0pM5veK isJL+OodoxRasD0BwkQb9LKVF0AvWlVPkF5GyT28zPXMKEY++Rapd72RARm8ZBXuetaU CHReqvUkCv4M8NTorBSHbrIUQ+5rCCDeLB8RSVEvQ2MLYMOypC/Lqrj+LGM2FGpa9Wo+ HPyq8esZN3sSHCTEdKtq7xE6TNljzyX7LGj3MOzwq88O+J/8i1KBbivmoSv7DDzRxnee +jRolS1qNXo4b8brFyBJq4HWc2xKleGYrKyBYOA6r1/EluPkSoexH05Hu75gSmFSyv1G 7Jgg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:message-id:references:in-reply-to :subject:cc:to:from:date:mime-version:sender:dkim-signature; bh=jY7jSMO0tANQEXmcwwRYlNgLnHP+314OK8EQwYmNDfw=; fh=+y4ZrTrtvsB1s3wu/k3znc8ORdegBvqbnDXDzZu3Ec0=; b=S1TO618Yno/vsiAw0mO1dIQxzqgSiVrSPUwcH/uf4oGYGFXDnzAZncMGdZKXniGfUx 68GbV4+zu7ISZ6PRS1aITNNXyyt/lP/hOce4ZjhL9uVD9Rve1/3ZVam6mfyUlXuCKe7N OyO9RdUxN8qAa3DMqPf5dq0pKVhNLsfg0mZV0RmI+620Q+5fOOOMe7oeytWImI4eXLpb 3E+yAkEA1lnNKJG3PLqYJ+GOGMh7Df6nFpwPFQ5xvQIh0n1osslAd8rtEz8kWSj64e6A JyrFHjfD3WEnQWvt4TsCTGv5y4HNS3CmQJbVV55DJZGipyl7MflyL7dFf3zJremDPAeJ cJsQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of dave@dtrt.org designates 208.79.240.5 as permitted sender) smtp.mailfrom=dave@dtrt.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1722318500; x=1722923300; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:message-id:references:in-reply-to:subject:cc:to :from:date:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=jY7jSMO0tANQEXmcwwRYlNgLnHP+314OK8EQwYmNDfw=; b=Tf6AK8peKfY7yPOUPdbZI2ylLf/Q37WYquhXDx7NLnA4bPUk5IN9x5Sfc4zJsHLdoq TgganN/pndrfFciKmKo0kAla80Z/pPQda1kmYzZC+zjDfh9AufXe30ABX+Cn1842R5fC ve/n9JUpW+yf4sxUOtMfcZ2MpW5KXSvfUF+9AkuZH17ukdQorrMuk8HXLV9z++KDRcuN 7PMrbdNnd2TiAK88nBNv3JsOGUamFlX62+2RvnC95jkpBl3g/FvKScz/GQODBSwMLpPM Mf2KT6zo6zMLKNrHYYCFJdVpkKnf8B2TAsZMv7I8yrTqx/MysHlef8uA1/s5B3p+7WkA KhHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722318500; x=1722923300; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:message-id:references:in-reply-to:subject:cc:to :from:date:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=jY7jSMO0tANQEXmcwwRYlNgLnHP+314OK8EQwYmNDfw=; b=iRkSH61usCrn6LDBEKlV5jerpSMUxrYVm6jLdXmwRQxO8zNFsXtCZCyYXnHaVydFcu kzlMjnqnaA5A54EqhmQwTyopQl3JZoBLw0dDtqbtLgcappKgsMRJb3iRM76DDfFWlrjF BuB+f6sLz7ff374coP+CAU1cCq9Bm8JvjfJ9P9E+86ZLytSql6Owx6arX8vbrmlC3tPr 3srUHg8hBiOtbASeVlc7Z4ABPDt+Jrf+gmu5mBIafJ0DmW7etTxYiKEkvm+Oe8mJWXcz KAlp22Q/C2GFFF3/CIo+XXSv72cHnsAhShc30Fdz8L1Ly3uRfrUdFXqiZ0S+9F6PazPO 5HjQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUfPbXQqdRopz4V9BamgwmnKP9YhQJ1cCjPJxAhgHNgukW+BgxIyv1Y17jMDyB0vNcceK0GWl4z460unKli3NAntnUcgWY= X-Gm-Message-State: AOJu0Yy+UoHndN60SR0mZ/t5mVY+Da6ER3lm4X/g+MA/nRxB1kdbr5Ek EQyecizVArSLsFqbXFjwX813wziS+sTptCWyRynvNKvJhglSxP3V X-Google-Smtp-Source: AGHT+IEuG6QH2FpIfOE9lUrXpu0fRmnIW/CiTRfS4yZVLv5j3VuIjc6uoLgzdXLoBTlda8ZIhARraw== X-Received: by 2002:a05:6870:164c:b0:261:21e9:1f19 with SMTP id 586e51a60fabf-267d4f03474mr11318736fac.35.1722318499341; Mon, 29 Jul 2024 22:48:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6871:a00d:b0:250:a95c:3b4d with SMTP id 586e51a60fabf-2649fcb66a8ls6697884fac.1.-pod-prod-03-us; Mon, 29 Jul 2024 22:48:17 -0700 (PDT) X-Received: by 2002:a05:6871:e282:b0:254:a233:3d28 with SMTP id 586e51a60fabf-267d4cd0f03mr21947fac.1.1722318497403; Mon, 29 Jul 2024 22:48:17 -0700 (PDT) Received: by 2002:a05:6808:d2:b0:3d9:3291:87dc with SMTP id 5614622812f47-3db1accbc20msb6e; Mon, 29 Jul 2024 21:57:23 -0700 (PDT) X-Received: by 2002:a05:6808:1b06:b0:3d9:da81:6d59 with SMTP id 5614622812f47-3db23ced37dmr14072274b6e.34.1722315441824; Mon, 29 Jul 2024 21:57:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1722315441; cv=none; d=google.com; s=arc-20160816; b=ArK+AL3RP3eprJRz2750VuCmxy54ENu2+F/VtgG/sjSUJOxORUXQmixTTgoLWvBxPN WAP6voeK+dFcpnmrx0goTWzdqtifRbKMPzp5/sVaBFoGbJi6wn45hW2R4Zwy/xxWZV8R 5zgFbqey90eyYK7ntC7KnyvVCtYsmY1e/oh5f8UluFmzHmoZAl0d1nwcK+tGB4QHv+nB wC4akShK1ggku3FqFMw4Exf05af4zB5Zn1r8/lKW9/OA8SuYZoP1ftTcWdB69Olq/HiP JEh4qzbGbReyLPO1PaSzB4wxWBNqss+rAej3IOHHHxj8DmQKRt5Z/CykEeKlbrpiQR1I NoWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:message-id:references:in-reply-to:subject :cc:to:from:date:mime-version; bh=P9JqHWD2n5OjRqonIPwKK++Wvqc2FP4FY3y8trTAtMw=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=Jx8mpw3p/UUJX/iRkb3H1L7Gd5dofxSw5RORF27I7hIqayuvvjpjGqEe6lqoY/f4J+ gAx5i/RIr1Q1R3ndeD4svYGVocIWsBggfJWquTYUEUXn6DxX8dz1Yq6c4XgPkzJ4vplN YjHjKw07D7R3xt+BC/39yZ70z1HPUWC1zZIIXJfnfTUHb+rzzQ5BIxVUZDOc4MJqdC7L CBzYDWB8GjlZasJkv+gAdudT+1Uxoixx5Z0DtTGfyBSki5wggH1tQVU2544+ZYYH3kK+ d7tQ6hBoulZw8dpiWNzATyPMSpewBczDWqBwuGIDu1/wHp0axmZpXAd4izc9WkQ+OFdz fZMw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of dave@dtrt.org designates 208.79.240.5 as permitted sender) smtp.mailfrom=dave@dtrt.org Received: from smtpauth.rollernet.us (smtpauth.rollernet.us. [208.79.240.5]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-7a9f5f2d1absi641948a12.1.2024.07.29.21.57.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jul 2024 21:57:21 -0700 (PDT) Received-SPF: pass (google.com: domain of dave@dtrt.org designates 208.79.240.5 as permitted sender) client-ip=208.79.240.5; Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 5F9F82800095; Mon, 29 Jul 2024 21:57:18 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Mon, 29 Jul 2024 21:57:18 -0700 (PDT) MIME-Version: 1.0 Date: Mon, 29 Jul 2024 18:57:17 -1000 From: "David A. Harding" To: Antoine Riard Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core In-Reply-To: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com> References: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com> Message-ID: <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset="UTF-8"; format=flowed X-Rollernet-Abuse: mailto:abuse@rollernet.us https://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 5b64.66a872ae.68c0.0 X-Original-Sender: dave@dtrt.org X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of dave@dtrt.org designates 208.79.240.5 as permitted sender) smtp.mailfrom=dave@dtrt.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) On 2024-07-20 16:10, Antoine Riard wrote: > If you or anoyone think TRUC as an alternative to the CPFP as a > transaction pinning mitigation as argued in its merged BIP is easy to > reason on [...] Before I address your full point, I think there are two separate things we want to reason about when considering a proposal like TRUC: - How does it affect operators of full nodes, including miners and volunteer relay node operators? - How does it affect existing and future protocol users? By "easy to reason about", I'm mainly referring to how TRUC will affect operators of full nodes. IMO, it's critical to get that part right. In comparing TRUC to RBFR, it seems to me that it's much easier to reason about TRUC's effect on relay behavior and mining profitability. When it comes to reasoning about pinning attacks against LN, this is almost fundamentally difficult owing to the difficulty of reasoning about any complex state protocol, especially one that interacts with multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P, Bitcoin consensus). Whether we're talking about CPFP, CPFP-CO, opt-in RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or anything else, reasoning about the full implications of a change for LN users will be difficult. IMO, when Bitcoin Core developers ship an opt-in feature like BIP431 TRUC, it is not their responsibility to ensure that it is perfectly safe for downstream projects. That onus falls on the downstream developers (e.g., LN devs). Of course, Bitcoin Core devs want to produce useful tools and that incentivizes them to produce actual safety improvements; however, it's unreasonable IMO to expect Bitcoin Core devs to understand a downstream protocol as well as the devs who work directly on that protocol. For something like imbued TRUC, it probably shouldn't be used to replace an existing mechanism that downstream devs depend on (see subsequent arguments) unless the downstream devs agree (or there's another very compelling reason). Again, the onus falls on the downstream developers to audit the mechanism's safety because they're the ones with theoretical and operational experience using the downstream protocol. Now on to your full point: > If you or anoyone think TRUC as an alternative to the CPFP as a > transsction pinning mitigation as argued in its merged BIP is easy to > reason on, thanks to communicate your lightning node pubkey, with TRUC > patch applied and a GPG-signed message authorizing me to demonstrate > the security properties of this solutions have not been submitted to a > fully contradictory evaluation. How would that work? AFAIK, there's no LN software using TRUC, very few relay nodes are using it (since it isn't yet enabled by default in a release version), and no miners are using it (again, since it hasn't been released). I'm willing to put money at stake to settle a disagreement that can't be settled with words, but I want to at least learn something from the process. My guess is that you're referring to the type of pinning attack you've called "loophole pinning"[1], which I don't entirely understand, so I'll do my best to describe it below and hopefully you can correct me on any errors: - Mallory guesses that, for the next 144 blocks, transactions in the mempool with a feerate of _x_ sats/vb will neither be confirmed nor evicted. If Mallory guesses wrong, the attack will fail. - Mallory controls a confirmed UTXO that she will spend in 10 different fee bumping transactions, making all of those transactions conflict. - Mallory has 10 channels. It doesn't matter whether these are all with the same counterparty, different counterparties, or a mix of counterparties. - In each channel: - Mallory causes the channel to contain the maximum number of in-flight HTLCs the counterparty will allow, creating state _A_. Each in-flight HTLC inflates the size of the commitment transaction about ~40 vbytes. The specification maximum for in-flight HTLCs is 2*483, but many implementations default to a lower value due to risks from other known attacks. - Mallory causes all of the in-flight HTLCs to be settled honestly, revoking state _A_ that contained them. - Mallory causes a single HTLC to be sent through the channel. Its satoshi value is chosen to be roughly equal to: x * (vbytes(A) + 1000), where _x_ is Mallory non-confirming-non-expiring feerate, vsize(A) is the size of the revoked commitment transaction, and 1,000 is the maximum size of a TRUC fee-bumping child. For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC value is 60,000 sat. - Although Mallory knows the preimage necessary to resolve the HTLC, she doesn't send it to her counterparty offchain. This will eventually force the counterparty to go onchain. - Mallory goes onchain first by broadcasting a package that consists of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size that pays a total fee equal to the pending HTLC value (e.g. 60,000 sat). - Notably, Mallory is doing this in 10 channels simultaneously with the fee bump for each spending the same UTXO, so all of those fee bumps conflict with each other. If Mallory broadcasts each package of revoked commitment transaction and fee bump to different nodes across the network, each particular package will only exist in the mempools of about 10% of nodes. - In some cases, Mallory's channel counterparty will receive the revoked commitment transaction via their own mempool monitoring code. - If they realize the feerate is below the amount necessary to get the transaction confirmed within the next 144 blocks, they will be able to CPFP fee bump the transaction themselves---but they will need to pay more than the 60,000 sat in fees that Mallory is offering. However, the pending HTLC is only worth 60,000 sat to them, so it may not make sense for them to fee bump. - In other cases, Mallory's channel counterparty will receive one of the conflicting packages. They will not know that a revoked commitment transaction has been broadcast. - When Mallory hasn't settled the HTLC fast enough, they will broadcast a package of their own commitment transaction and their own CPFP fee bump child. This will pay a higher feerate than Mallory paid (which is possible to do under the 60,000 sat budget because they're using much smaller transactions). - Their high feerate package will propagate until it encounters relay nodes that have their channel's revoked commitment transaction. Although the counterparty's transaction pays a higher feerate, it pays less absolute fees than Mallory's transaction and will be rejected by that relay node. - In any cases where the pinning prevents confirmation within 144 blocks, the HTLC's upstream node can claim a refund and Mallory can then use her preimage to steal the HTLC value from her counterparty, completing the attack successfully. - To settle the HTLC with its preimage, Mallory needs to pay more absolute fees to remove her pin, but because she pinned 10 channels with a single UTXO, paying to remove the pin from one channel and getting that spend confirmed will automatically remove the pin from all other channels. In other words, her cost per channel is roughly 10% what her honest counterparties would've had to pay to remove the pin. - However, once Mallory's pin is removed, all the counterparties should still broadcast spends of the HTLC-Failure transaction paying the HTLC's full value to fees in order to deprive Mallory of any profit. Given the first point and the last point, I'm not sure how viable the attack is (but, as I said, I'm not sure I understand it). Estimating or manipulating feerates correctly for over 144 blocks in a row sounds difficult. Counterparties being able to deprive Mallory of profit seems like a major weakness. Looking at other proposed improvements: one-shot RBFR with its requirement that fee bumps enter the top portion of the mempool may avoid this type of pinning; ideas for expanded versions of TRUC that also require entering the top portion of the mempool may also avoid this type of pinning, e.g. "TRUC v3.0.5".[2] > About replace-by-feerate, I think it's a solution that have downside > on its own, especially for second-layers like lightning. If it looked like RBFR was going to be widely deployed, I think its effect on LN would definitely warrant more research. > And as I observed on one of the V3 PR threads and corresponding > conversations, the CPFP carve-out do not provide > security to lightning implementation > [...] > So unless someone argued to the contrary, saying TRUC was needed to > then deploy cluster mempool is an intellectual fallacy You described several attacks against anchor outputs using CPFP-CO, some of which sound quite plausible to me, but none of them is certain to succeed in any particular instance. By comparison, disabling CPFP-CO would leave all users of anchor outputs immediately vulnerable to the original pinning attack that has an expected ~100% success rate and barely any cost if executed against multiple channels simultaneously. Given that, it makes no sense to disable CPFP-CO until a successor is available. > On my personal perspective, and after careful considerations of all > the technical points you've raised. I still think TRUC has a lot of > problems. RBRFr too has technical problems. About TRUC I think it's an > acceptable temporary solution to minimize the pinning surface of > lightning implementations, pending for the design of a better solution > (more likely at the consensus-level [...]) Thank you for your opinion. I too think TRUC is a good solution until we find something better, and any significant improvements may indeed require consensus changes. -Dave [1] https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1888377830 [2] https://delvingbitcoin.org/t/v3-and-some-possible-futures/523 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/4e959cdbe70b1a3b9f1adb37fe3b986e%40dtrt.org.