Delivery-date: Thu, 15 Aug 2024 21:47:31 -0700 Received: from mail-yb1-f190.google.com ([209.85.219.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1seos3-0001zz-O4 for bitcoindev@gnusha.org; Thu, 15 Aug 2024 21:47:30 -0700 Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e1169005d9asf2865742276.0 for ; Thu, 15 Aug 2024 21:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1723783641; x=1724388441; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=iqS/uxK+66NrwEF9lRgHZPGsQ8WTqq/p+KEOp7POpHw=; b=ofruvpi+3bUa612obfzNYimxT5uckMpXm/9kbwoeIiEL5XsZitdhDJGtHj5RET7hiW tpFJ8BEpHIFPXzPte5JL/wv5xDY+hvsqnb1EIDpxG4wgKyXk4J6lMxoElSrR9Ookiga4 1Rm3PZX/BVpubLvdw6he1eHkF0d3Ql3PIgtFeLX/uAMnBvVzrVHD4FGArhdt3+nTLMiG H9wqQaFcCcVLZijn0Uyl9sZR7guCW2uMYn1i3rX5c+Ley4LxYBIllVywhvkp3ARw1LSp 9/SGzBRriCS7jn1LH1sC/XEnS1WgR+apE4LiDETPGMD5xRuWCS4RXKaS8uz1ZmrIvmyZ ps2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723783641; x=1724388441; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=iqS/uxK+66NrwEF9lRgHZPGsQ8WTqq/p+KEOp7POpHw=; b=JJPs8cef3eDvft4aP/LTAuCRpm50aDf3CVoJZz2v0cyj68a4mwtW0aURcyUqzUXQ+2 vVCoFN3cT6SZsHsm/zpy474N2yy3gzSxPoKODwfE/5vbtAsptojf9WioaXsTnFtCw7qH vVnUaDJjbWXJT8htct9dcXiOtKjhH2qRxmZO50DHNYmQCaLVoZRV9VrSyLstZ57DuDk2 yZIPgXPud1TP3t9v1vFps2PkMbQIVuqSk/MPvaTgA/iefqeNEcSpXwJeCLNHEv00z6E3 DLPfqw4dDkayRhFBCknZy5FHUl4/4jazpWy3+C+L5csxvfmOv5zD75yFObMFqlkw5wOf FWiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723783641; x=1724388441; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=iqS/uxK+66NrwEF9lRgHZPGsQ8WTqq/p+KEOp7POpHw=; b=BP9MxDMKFgqSR3bXmcdRtqyVSaF/xqp2pfP0lpmRqO1TerSIQymLqD010bLSuJq3Be HM9qS0makRCMSagDEg6mJaSrnDucuPiXXqJdpHKkbVcHWBOnge2jfDAqpNlYYa5wPpgh KtKTNbjAkcibJUK83WcEo5uxxxhGI+wxZJvi/A/qXEd3b3EcrLj3RmebPMbkJSGnvc2X +P6fe7uPjlwEYHXXsTqduqKRPLUyoDHCrc4u6edF/YIWQKxXPxMslAEAZo1YESPvSyF/ sT7gJncWYp3VqRmXWIfcTXYrj2T6+C2XZYHOa/53KE6AyzD7usisq6vSQcKzDnnO+B0u y4vA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWsHoStqpV2w0q7rRBtFX888PGVXHrMMpc7M/Y3ytWnDvMMK0+E22m0b0dbzkEQPN9Kwvj7fiDRplTmBdePLV90mtdvDM8= X-Gm-Message-State: AOJu0YwMUwzs1M/lOQ1luxSdDlXBhXUNuFalnEXI2VF0itsMVbWuvYQk zwRGa6JBlISjB3uwF90HB/9vgb+a8cPKyUJI3AFwMAFkX/M2GdJl X-Google-Smtp-Source: AGHT+IHWnkqaxplhaKBbt6HmbRQ9tl2gf/DeMbRus7iRJHKzeBYXVTv+Fo2bmuQHf4y1GaMBYrRZ4g== X-Received: by 2002:a05:6902:723:b0:e11:5d18:2ade with SMTP id 3f1490d57ef6-e1180ef8200mr2536520276.29.1723783640738; Thu, 15 Aug 2024 21:47:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:100b:b0:e03:64a5:8bb0 with SMTP id 3f1490d57ef6-e116beb5998ls1693685276.1.-pod-prod-00-us; Thu, 15 Aug 2024 21:47:18 -0700 (PDT) X-Received: by 2002:a25:dc01:0:b0:e0b:b36e:d73d with SMTP id 3f1490d57ef6-e116ce89a47mr71514276.4.1723783638775; Thu, 15 Aug 2024 21:47:18 -0700 (PDT) Received: by 2002:a05:690c:4883:b0:66a:8967:a513 with SMTP id 00721157ae682-6ad31665915ms7b3; Thu, 15 Aug 2024 21:20:39 -0700 (PDT) X-Received: by 2002:a05:690c:368a:b0:68d:52a1:bf4 with SMTP id 00721157ae682-6b1b7597dbamr1361577b3.2.1723782038599; Thu, 15 Aug 2024 21:20:38 -0700 (PDT) Date: Thu, 15 Aug 2024 21:20:38 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <11b7ba56-04f1-4ebe-a434-e8478b5efe70n@googlegroups.com> In-Reply-To: <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org> References: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com> <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org> Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_25718_869047551.1723782038417" X-Original-Sender: antoine.riard@gmail.com 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.5 (/) ------=_Part_25718_869047551.1723782038417 Content-Type: multipart/alternative; boundary="----=_Part_25719_1015100085.1723782038417" ------=_Part_25719_1015100085.1723782038417 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, Apologies for the late answer, I was hiking in nature over the past few=20 days. > Before I address your full point, I think there are two separate things > we want to reason about when considering a proposal like TRUC: >=20 > - How does it affect operators of full nodes, including miners and > volunteer relay node operators? >=20 > - How does it affect existing and future protocol users? >=20 > 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. I think it's a correct categorization, with the observation that it can be= =20 more interesting to dissociate miners from volunteer relay node operators in the= =20 analysis of a proposal like TRUC. Miners have the ability to discretely mine=20 non-standard transactions in their block template, contrary of relay nodes. This=20 observation matters practically e.g w.r.t dust HTLC exposure where miners have an edge= =20 to launch that type of attacks. > 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. I don't deny it, with the addition that you have to reason on how the LN game-theory incentives can play out, in a system where all the balances are denominated in satoshis, a scarce ressource under the max money=20 consensus limit. And I'll keep the conversation simple, as there is always the risk when you're designing second-layers protocol extensions to have backfire coupling effects on the base-layer (-- one of the main technical reason we never actually rolled out forward the proof-of-UTXO ownership designed with naumenkogs as a channel jamming mitigation is the base-layer spam risks introduced to bypass it). > 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. This is where we have a strong divergence, with all my appreciation of your= =20 viewpoint. In my opinion this shall be the responsibility of the Bitcoin Core=20 developers to ensure there is a reasonable safety of the design and implemented=20 mechanism for downstream projects. Experience of the last years, most notably the half of dozen of security=20 weakness loss of funds found in the design or implementation of anchor outputs (the= =20 lack of carve out support at first, the revocation escape, the new pinning vector= =20 due to legacy merging of second-stage transactions, the parsing error of core=20 lightning / lnd...) can only point out to seasoned technical observers that weakness=20 arises because of the poor understanding of protocols operational inter-dependency. That practical bitcoin experience is matching some observations documented= =20 by the IETF in decades of design and development of the TCP / IP stack (RFC 3439) [0].= =20 Under the coupling principle, that as things gets larger, they often exhibit increased=20 inter-dependence between components, and with unforseen feature interaction. In the bitcoin space a= =20 good incarnation is all the bip125 rule 3 based economical pinnings, that I don't believe=20 were clearly expected by their bip authors. [0] https://www.rfc-editor.org/rfc/rfc3439 Obviously, there is a sense of proportion to guard and that all Bitcoin=20 Core devs shall understand downstream protocols as well as the devs who work directly= =20 on that protocol does not appear realistic, given the wider variety of other=20 subsystems such as builds, graphic interface or p2p block-relay protocol. _However_, I strongly believe that Bitcoin Core devs working in the=20 subsystem interfacing with downstream protocols such as the mempool or the=20 transaction-relay protocol should have an understood as good as the downstream devs of said= =20 protocol inner workings. Otherwise, by designing, implementing and deploying weak=20 proposals such as TRUC in its earlier versions they might cause more harms than good,= =20 on the _long term_. One cannot said there was technical consensus with the merge of TRUC, in=20 the sense of lack of standing grounded objections, be it by the RBFR author, or=20 myself directly on the PR / issues implementing this design in Bitcoin Core. > 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. One should not forget that downstream protocol devs and contributors e.g=20 for lightning are mostly working for commercial companies, with for some on short=20 business timelines. This is very likely to induce them to pick up an expedient mechanism,=20 without fully auditing it, more than jeopardizing the end-users funds safety (and the=20 crypto space at large does not miss spectacular vulnerabilities exploitation). Sadly, one cannot expect that Bitcoin Core devs contributors to be immune= =20 of short-term external factors in the design of better mempool mechanism as in 2020 while= =20 I was advocating to build a better understanding of cross-layers security among contributors= =20 [1]. Yet, at the very same time the current author of TRUC and bip331 was doing a=20 round of the medias to "sell" the idea and correspondingly attract open-source funding= =20 before there was even the lineaments of a technical consensus among contributors to the= =20 Bitcoin Core project, or what you call the downstream devs like lightning [2]. [1]=20 https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/0028= 56.html [2]=20 https://bitcoinmagazine.com/technical/gloria-zhao-and-brink-are-set-to-give= -bitcoin-mempools-an-upgrade (It's not like there has been a precedent in bitcoin development with the= =20 extension block bip idea from joseph poon...which was proposed in 2017 in a fashion= =20 less than usual w.r.t traditional communication channels...) So yes, I think there should be a cultural change in terms of design and=20 deployment of p2p or mempool policy mechanisms supporting downstream protocols. In my= =20 opinion, which is backed by my first code review of the imbuance mechanism, current= =20 development process is still on the same pace, heading us in nurturing more cross-layer= =20 vectors of attacks like pinning due to complex misinterfacing or mempoolfullrbf=20 default-like difficult campaigns of deprecation. > 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. Thank you for the offer of setting up a demo infrastructure for pinning=20 attacks experiment. I'll describe more what is the minimal setup needed in another public email= =20 thread or on delving bitcoin. Less than the funds in the channel, it's interesting= =20 to have a full vanilla configuration on mainnet to avoid running in the myriad of= =20 cases with policy standardss and the mempool congestion roallcoaster on whatever is=20 the testnet / signet of the day. I can even put the satosis for funding the channnels if= =20 it's really needed. It's correct that TRUC is not implemented in LN in where commitments=20 transactions are nVersion field updated to be pre-signed with TRUC semantics... I can=20 always write a patch in C or rust to have test code ? Though here I would play=20 both the attacker and defender role in the experiment. At least, I think it would be= =20 worthwile on its own to test current bip125 rule 3-based economic pinnings, without= =20 TRUC usage. > 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: >=20 > - 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. >=20 > - Mallory controls a confirmed UTXO that she will spend in 10 different > fee bumping transactions, making all of those transactions conflict. >=20 > - Mallory has 10 channels. It doesn't matter whether these are all with > the same counterparty, different counterparties, or a mix of > counterparties. >=20 > - In each channel: >=20 > - 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. >=20 > 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. >=20 > - Mallory causes all of the in-flight HTLCs to be settled honestly, > revoking state _A_ that contained them. >=20 > - 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. >=20 > For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC > value is 60,000 sat. >=20 > - 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. >=20 > - 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). >=20 > - 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. >=20 > - In some cases, Mallory's channel counterparty will receive the > revoked > commitment transaction via their own mempool monitoring code. >=20 > - 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. >=20 > - 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. >=20 > - 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). >=20 > - 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. >=20 > - 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. >=20 > - 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. The assumption is correct that Mallory makes a prediction on a level of mempool congestion for a target feerate group, and this is a factor or success or not of the attack. It should be noted, there is no need to revoke the state or not in this pinning, one can use the non-revoked consensus valid transaction, I think this is the main difference with my scenario where non-revoked transactions are used to do the "staggering" package (i.e the one at 60,000 sat in your example), before to be "unstagged" by the same absolute fee, higher feerate= , penalty-paying package. The parallelization can allow the attacker to not pay the cost, there is no necessity that it is happening on parallel channels, as one can=20 double-spend from the CPFP of a "batching transaction, whatever else it is doing. > Given the first point and the last point, I'm not sure how viable the=20 > attack is (but, as I said, I'm not sure I understand it). Estimating or= =20 > manipulating feerates correctly for over 144 blocks in a row sounds=20 > difficult. Counterparties being able to deprive Mallory of profit seems= =20 > like a major weakness.=20 On the first point, if I'm understanding correctly it's about predicting mempool congestion as a factor of success of the attack. It's not a perfect art though it's quite practical for an attacker as it is what mempool fee estimation algorithms are all about. On the last point, i.e the HTLC-Failure transaction paying the full value to the fees, this HTLC-Failure confirmation should happen only after the double-spend of the inbound HTLC by a puppet of Mallory. Until this on-chai= n confirmation of the malicious inbound HTLC-failure, the Alice's outbound HTLC-failure is blocked by the pinning. Note, this is _not_ a replacement cycling attack, as it's all relying on th= e Mallory's package being on an absolute fee / feerate too high to be replace= d by a Alice's package. I understand it's hard to understand, and it sounds your attack layout coul= d benefit from adding lightning topology on the left / right side of Alice as the attack victim. Note, how mempool congestion could play as a pinning=20 vector was slightly surveyed in the discussion of package relay design in 2020,=20 though no more fleshed-out write-up or blog post has been made available since=20 then until my comment on the Bitcoin Core PR, to the best of my knowledge [4]. [4] https://github.com/bitcoin/bitcoin/issues/14895#issuecomment-665907792 > Looking at other proposed improvements: one-shot RBFR with its=20 > requirement that fee bumps enter the top portion of the mempool may=20 > avoid this type of pinning; ideas for expanded versions of TRUC that=20 > also require entering the top portion of the mempool may also avoid this= =20 > type of pinning, e.g. "TRUC v3.0.5".[2]. I have not yet analyzed one-shot RBFR in more detailed, though I believe a better long-term fix is actually _not_ to entangle the mempool states wit= h transaction-relay propagation rules. A full-node mempoool is a stateful cache with public write allowed. > If it looked like RBFR was going to be widely deployed, I think its > effect on LN would definitely warrant more research. If mempool acceptance was more modular in Bitcoin Core, we could have more fine-grained transaction acceptance policy module embedded in the `AcceptToMemoryPool` flow and easier to experiment the effects of alternative policy like RBFR on LN. > 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. >=20 > Given that, it makes no sense to disable CPFP-CO until a successor is > available. In a world where revoked lightning transactions are still consensus-valid and where any of them can be used to blind the lightning node of the correc= t CPFP to proceed with, the carve-out is ineffective. I'll let you indicate me where in the bolt spec it is indicated how=20 lightning software should implement correctly CPFP of the carve-out, as it is=20 implemented and deployed in Bitcoin Core since circa 2019. I won't say the carve-out mechanism has been "fast" shipped in 2019 and tha= t its authors might really not know how lightnning was working at the time. However, I believe there has never been a bip or other document informing= =20 how it should be used by downtream protocols. > 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. Thank too for your opinion. I think TRUC is an acceptable temporary solutio= n to minimize lightning pinning surface, however I'm still worried on the=20 long-term it can have undesirable side-effect, in a world where miners are running=20 "heretic" transaction acceptance policy. And it's making a false security guarantee for lightning nodes, as uniform= =20 policy is not a network reality, and an associated full-node could be paired with= =20 peers not respecting TRUC semantics -- I know I've advocated uniform policy w.r.t= =20 package relay to improve lightning safety in the past, though after finding vulnerability= =20 vectors arising from a policy rule like opt-in RBF and asymmetrically affecting use-cases= =20 (0conf vs LN), I'm far more skeptical in grounding downstream protocols safety on mechanism=20 like TRUC. Best, Antoine ots hash: 42407994c5e58123bf2535ba420517f83b95977052b4bde4ff9e115b91e2b598 Le mardi 30 juillet 2024 =C3=A0 06:48:19 UTC+1, David A. Harding a =C3=A9cr= it : > 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=20 > revoked > commitment transaction via their own mempool monitoring code. > > - If they realize the feerate is below the amount necessary to get=20 > the > transaction confirmed within the next 144 blocks, they will be=20 > 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=20 > 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=20 > 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]=20 > https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1888377830 > [2] https://delvingbitcoin.org/t/v3-and-some-possible-futures/523 > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/11b7ba56-04f1-4ebe-a434-e8478b5efe70n%40googlegroups.com. ------=_Part_25719_1015100085.1723782038417 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave,

Apologies for the late answer, I was hiking in nature o= ver the past few days.

> 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 no= de 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 effec= t on relay behavior and mining profitability.

I think it's a cor= rect categorization, with the observation that it can be more
interest= ing to dissociate miners from volunteer relay node operators in the analysi= s
of a proposal like TRUC. Miners have the ability to discretely mine = non-standard
transactions in their block template, contrary of relay n= odes. This observation
matters practically e.g w.r.t dust HTLC exposur= e where miners have an edge to
launch that type of attacks.

> When it comes to reasoning about pinning attacks against LN, this is<= br />> almost fundamentally difficult owing to the difficulty of reasoni= ng
> about any complex state protocol, especially one that interact= s 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, C= TV, CAT, TRUC, or
> anything else, reasoning about the full implica= tions of a change for LN
> users will be difficult.

I do= n't deny it, with the addition that you have to reason on how the LN
g= ame-theory incentives can play out, in a system where all the balances
are denominated in satoshis, a scarce ressource under the max money consen= sus
limit. And I'll keep the conversation simple, as there is always t= he risk
when you're designing second-layers protocol extensions to hav= e backfire
coupling effects on the base-layer (-- one of the main tech= nical reason
we never actually rolled out forward the proof-of-UTXO ow= nership designed
with naumenkogs as a channel jamming mitigation is th= e base-layer spam
risks introduced to bypass it).

> 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 develope= rs
> (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 Co= re devs to understand
> a downstream protocol as well as the devs w= ho work directly on that
> protocol.

This is where we ha= ve a strong divergence, with all my appreciation of your viewpoint.
In my opinion this shall be the responsibility of the Bitcoin Core deve= lopers
to ensure there is a reasonable safety of the design and implem= ented mechanism
for downstream projects.

Experience of the = last years, most notably the half of dozen of security weakness
loss o= f funds found in the design or implementation of anchor outputs (the lack o= f
carve out support at first, the revocation escape, the new pinning v= ector due to
legacy merging of second-stage transactions, the parsing = error of core lightning /
lnd...) can only point out to seasoned techn= ical observers that weakness arises because
of the poor understanding = of protocols operational inter-dependency.

That practical bitcoi= n experience is matching some observations documented by the IETF
in d= ecades of design and development of the TCP / IP stack (RFC 3439) [0]. Unde= r the coupling
principle, that as things gets larger, they often exhib= it increased inter-dependence between
components, and with unforseen f= eature interaction. In the bitcoin space a good incarnation
is all the= bip125 rule 3 based economical pinnings, that I don't believe were clearly= expected
by their bip authors.

[0] https://www.rfc-editor.= org/rfc/rfc3439

Obviously, there is a sense of proportion to gua= rd and that all Bitcoin Core devs
shall understand downstream protocol= s as well as the devs who work directly on that
protocol does not appe= ar realistic, given the wider variety of other subsystems
such as buil= ds, graphic interface or p2p block-relay protocol.

_However_, I = strongly believe that Bitcoin Core devs working in the subsystem
inter= facing with downstream protocols such as the mempool or the transaction-rel= ay
protocol should have an understood as good as the downstream devs o= f said protocol
inner workings. Otherwise, by designing, implementing = and deploying weak proposals
such as TRUC in its earlier versions they= might cause more harms than good, on the
_long term_.

One = cannot said there was technical consensus with the merge of TRUC, in the se= nse
of lack of standing grounded objections, be it by the RBFR author,= or myself directly
on the PR / issues implementing this design in Bit= coin Core.

> For something like imbued TRUC, it probably shou= ldn't be used to replace
> an existing mechanism that downstream de= vs depend on (see subsequent
> arguments) unless the downstream dev= s agree (or there's another very
> compelling reason). Again, the o= nus falls on the downstream developers
> to audit the mechanism's s= afety because they're the ones with
> theoretical and operational e= xperience using the downstream protocol.

One should not forget t= hat downstream protocol devs and contributors e.g for lightning
are mo= stly working for commercial companies, with for some on short business time= lines.
This is very likely to induce them to pick up an expedient mech= anism, without fully
auditing it, more than jeopardizing the end-users= funds safety (and the crypto space
at large does not miss spectacular= vulnerabilities exploitation).

Sadly, one cannot expect that Bi= tcoin Core devs contributors to be immune of short-term
external facto= rs in the design of better mempool mechanism as in 2020 while I was advocat= ing
to build a better understanding of cross-layers security among con= tributors [1]. Yet,
at the very same time the current author of TRUC a= nd bip331 was doing a round of the
medias to "sell" the idea and corre= spondingly attract open-source funding before there
was even the linea= ments of a technical consensus among contributors to the Bitcoin Core proje= ct,
or what you call the downstream devs like lightning [2].

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-Octobe= r/002856.html
[2] https://bitcoinmagazine.com/technical/gloria-zhao-an= d-brink-are-set-to-give-bitcoin-mempools-an-upgrade

(It's not li= ke there has been a precedent in bitcoin development with the extension
block bip idea from joseph poon...which was proposed in 2017 in a fashion= less than usual
w.r.t traditional communication channels...)
So yes, I think there should be a cultural change in terms of design and= deployment
of p2p or mempool policy mechanisms supporting downstream = protocols. In my opinion,
which is backed by my first code review of t= he imbuance mechanism, current development
process is still on the sam= e pace, heading us in nurturing more cross-layer vectors
of attacks li= ke pinning due to complex misinterfacing or mempoolfullrbf default-like
difficult campaigns of deprecation.

> If you or anoyone thi= nk TRUC as an alternative to the CPFP as a
> transsction pinning mi= tigation as argued in its merged BIP is easy to
> reason on, thanks= to communicate your lightning node pubkey, with TRUC
> patch appli= ed and a GPG-signed message authorizing me to demonstrate
> the sec= urity properties of this solutions have not been submitted to a
> f= ully 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 tha= t can't be settled with words, but I want to at least
> learn somet= hing from the process.

Thank you for the offer of setting up a d= emo infrastructure for pinning attacks experiment.
I'll describe more = what is the minimal setup needed in another public email thread
or on = delving bitcoin. Less than the funds in the channel, it's interesting to ha= ve
a full vanilla configuration on mainnet to avoid running in the myr= iad of cases with
policy standardss and the mempool congestion roallco= aster on whatever is the testnet /
signet of the day. I can even put t= he satosis for funding the channnels if it's really
needed.

It's correct that TRUC is not implemented in LN in where commitments trans= actions
are nVersion field updated to be pre-signed with TRUC semantic= s... I can always
write a patch in C or rust to have test code ? Thoug= h here I would play both the
attacker and defender role in the experim= ent. At least, I think it would be worthwile
on its own to test curren= t bip125 rule 3-based economic pinnings, without TRUC usage.

>= ; 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 corre= ct me on any
> errors:
>
> - Mallory guesses that,= for the next 144 blocks, transactions in the
> mempool with a feer= ate of _x_ sats/vb will neither be confirmed nor
> evicted. If Mall= ory guesses wrong, the attack will fail.
>
> - Mallory con= trols a confirmed UTXO that she will spend in 10 different
> fee bu= mping 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 o= f
> counterparties.
>
> - In each channel:
&g= t;
> - 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 transact= ion
> about ~40 vbytes.
>
> The specification maxi= mum for in-flight HTLCs is 2*483, but many
> implementations defaul= t to a lower value due to risks from other
> known attacks.
&g= t;
> - Mallory causes all of the in-flight HTLCs to be settled hon= estly,
> revoking state _A_ that contained them.
>
&g= t; - 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
&= gt; 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 coun= terparty to go onchain.
>
> - Mallory goes onchain first b= y broadcasting a package that consists
> of the revoked state _A_ a= nd a CPFP fee bump 1,000 vbytes in size
> that pays a total fee equ= al to the pending HTLC value (e.g. 60,000
> sat).
>
&= gt; - Notably, Mallory is doing this in 10 channels simultaneously with the=
> fee bump for each spending the same UTXO, so all of those fee bu= mps
> 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 t= he 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 necessar= y to get
> the
> transaction confirmed within the next 144 = blocks, they will be
> able
> to CPFP fee bump the transact= ion themselves---but they will need
> to pay more than the 60,000 s= at 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 coun= terparty 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 fas= t enough, they will
> broadcast a package of their own commitment t= ransaction and their
> own CPFP fee bump child. This will pay a hig= her 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 i= t encounters
> relay
> nodes that have their channel's revo= ked commitment transaction.
> Although the counterparty's transacti= on 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 sett= le 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
> gett= ing that spend confirmed will automatically remove the pin from
> a= ll 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, a= ll the counterparties
> should still broadcast spends of the HTLC-F= ailure transaction
> paying the HTLC's full value to fees in order = to deprive Mallory
> of any profit.

The assumption is co= rrect that Mallory makes a prediction on a level of
mempool congestion= for a target feerate group, and this is a factor or
success or not of= the attack.

It should be noted, there is no need to revoke the = state or not in this
pinning, one can use the non-revoked consensus va= lid transaction, I think
this is the main difference with my scenario = where non-revoked transactions
are used to do the "staggering" package= (i.e the one at 60,000 sat in your
example), before to be "unstagged"= by the same absolute fee, higher feerate,
penalty-paying package.

The parallelization can allow the attacker to not pay the cost, the= re is
no necessity that it is happening on parallel channels, as one c= an double-spend
from the CPFP of a "batching transaction, whatever els= e it is doing.

> Given the first point and the last point, I'= m not sure how viable the
> attack is (but, as I said, I'm not sur= e I understand it). Estimating or
> manipulating feerates correctl= y for over 144 blocks in a row sounds
> difficult. Counterparties = being able to deprive Mallory of profit seems
> like a major weakn= ess.

On the first point, if I'm understanding correctly it's ab= out predicting
mempool congestion as a factor of success of the attack= . It's not a perfect
art though it's quite practical for an attacker a= s it is what mempool fee
estimation algorithms are all about.
On the last point, i.e the HTLC-Failure transaction paying the full valu= e
to the fees, this HTLC-Failure confirmation should happen only after= the
double-spend of the inbound HTLC by a puppet of Mallory. Until th= is on-chain
confirmation of the malicious inbound HTLC-failure, the Al= ice's outbound
HTLC-failure is blocked by the pinning.

Note= , this is _not_ a replacement cycling attack, as it's all relying on theMallory's package being on an absolute fee / feerate too high to be repl= aced
by a Alice's package.

I understand it's hard to unders= tand, and it sounds your attack layout could
benefit from adding light= ning topology on the left / right side of Alice as
the attack victim. = Note, how mempool congestion could play as a pinning vector
was slight= ly surveyed in the discussion of package relay design in 2020, though
= no more fleshed-out write-up or blog post has been made available since the= n until
my comment on the Bitcoin Core PR, to the best of my knowledge= [4].

[4] https://github.com/bitcoin/bitcoin/issues/14895#issuec= omment-665907792

> Looking at other proposed improvements: on= e-shot RBFR with its
> requirement that fee bumps enter the top po= rtion of the mempool may
> avoid this type of pinning; ideas for e= xpanded versions of TRUC that
> also require entering the top port= ion of the mempool may also avoid this
> type of pinning, e.g. "TR= UC v3.0.5".[2].

I have not yet analyzed one-shot RBFR in more de= tailed, though I believe
a better long-term fix is actually _not_ to e= ntangle the mempool states with
transaction-relay propagation rules. A= full-node mempoool is a stateful
cache with public write allowed.

> If it looked like RBFR was going to be widely deployed, I thin= k its
> effect on LN would definitely warrant more research.
<= br />If mempool acceptance was more modular in Bitcoin Core, we could have<= br />more fine-grained transaction acceptance policy module embedded in
the `AcceptToMemoryPool` flow and easier to experiment the effects of
alternative policy like RBFR on LN.

> You described several= attacks against anchor outputs using CPFP-CO, some
> of which soun= d quite plausible to me, but none of them is certain to
> succeed i= n 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
&g= t; barely any cost if executed against multiple channels simultaneously.>
> Given that, it makes no sense to disable CPFP-CO until a= successor is
> available.

In a world where revoked ligh= tning transactions are still consensus-valid
and where any of them can= be used to blind the lightning node of the correct
CPFP to proceed wi= th, the carve-out is ineffective.

I'll let you indicate me where= in the bolt spec it is indicated how lightning
software should implem= ent correctly CPFP of the carve-out, as it is implemented
and deployed= in Bitcoin Core since circa 2019.

I won't say the carve-out mec= hanism has been "fast" shipped in 2019 and that
its authors might real= ly not know how lightnning was working at the time.
However, I believe= there has never been a bip or other document informing how it
should = be used by downtream protocols.

> Thank you for your opinion.= I too think TRUC is a good solution until
> we find something bett= er, and any significant improvements may indeed
> require consensus= changes.

Thank too for your opinion. I think TRUC is an accepta= ble temporary solution
to minimize lightning pinning surface, however = I'm still worried on the long-term
it can have undesirable side-effect= , in a world where miners are running "heretic"
transaction acceptance= policy.

And it's making a false security guarantee for lightnin= g nodes, as uniform policy
is not a network reality, and an associated= full-node could be paired with peers
not respecting TRUC semantics --= I know I've advocated uniform policy w.r.t package relay
to improve li= ghtning safety in the past, though after finding vulnerability vectors aris= ing
from a policy rule like opt-in RBF and asymmetrically affecting us= e-cases (0conf vs LN), I'm
far more skeptical in grounding downstream = protocols safety on mechanism like TRUC.

Best,
Antoine
ots hash: 42407994c5e58123bf2535ba420517f83b95977052b4bde4ff9e115b91e2b598=

Le mardi 30 juillet 2024 =C3=A0 06:48:19 UTC+1, David A. Harding a= =C3=A9crit=C2=A0:
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 TR= UC 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 rea= son
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 saf= e
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 under= stand
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 re= place
an existing mechanism that downstream devs depend on (see subsequent
arguments) unless the downstream devs agree (or there's another ver= y
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 demonstra= te
> 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, ver= y 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 lea= st
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 unde= rstand, 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 transactio= n
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 HT= LC
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 acros= s
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= =20
revoked
commitment transaction via their own mempool monitoring code.

- If they realize the feerate is below the amount necessary to get= =20
the
transaction confirmed within the next 144 blocks, they will be= =20
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 i= t
may not make sense for them to fee bump.

- In other cases, Mallory's channel counterparty will receive on= e of=20
the
conflicting packages. They will not know that a revoked commitmen= t
transaction has been broadcast.

- When Mallory hasn't settled the HTLC fast enough, they will
broadcast a package of their own commitment transaction and thei= r
own CPFP fee bump child. This will pay a higher feerate than
Mallory paid (which is possible to do under the 60,000 sat budge= t
because they're using much smaller transactions).

- Their high feerate package will propagate until it encounters=20
relay
nodes that have their channel's revoked commitment transacti= on.
Although the counterparty's transaction pays a higher feerat= e, 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 channel= s
with a single UTXO, paying to remove the pin from one channel and
getting that spend confirmed will automatically remove the pin fro= m
all other channels. In other words, her cost per channel is rough= ly
10% what her honest counterparties would've had to pay to remo= ve the
pin.

- However, once Mallory's pin is removed, all the counterparti= es
should still broadcast spends of the HTLC-Failure transaction
paying the HTLC's full value to fees in order to deprive Mal= lory
of any profit.

Given the first point and the last point, I'm not sure how viable t= he
attack is (but, as I said, I'm not sure I understand it). Estimati= ng or
manipulating feerates correctly for over 144 blocks in a row sounds
difficult. Counterparties being able to deprive Mallory of profit seem= s
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 thi= s
type of pinning, e.g. "TRUC v3.0.5".[2]

> About replace-by-feerate, I think it's a solution that have do= wnside
> 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 t= o
> then deploy cluster mempool is an intellectual fallacy

You described several attacks against anchor outputs using CPFP-CO, som= e
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 al= l
> the technical points you've raised. I still think TRUC has a l= ot of
> problems. RBRFr too has technical problems. About TRUC I think it&= #39;s an
> acceptable temporary solution to minimize the pinning surface of
> lightning implementations, pending for the design of a better solu= tion
> (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]=20
https://github.com/bitcoin/bi= tcoin/pull/28948#issuecomment-1888377830
[2] https://delvingbitcoin.org/t/v3-and-some-p= ossible-futures/523

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/11b7ba56-04f1-4ebe-a434-e8478b5efe70n%40googlegroups.com.=
------=_Part_25719_1015100085.1723782038417-- ------=_Part_25718_869047551.1723782038417--