Hi Dave, Apologies for the late answer, I was hiking in nature over 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 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. I think it's a correct categorization, with the observation that it can be more interesting to dissociate miners from volunteer relay node operators in the analysis of a proposal like TRUC. Miners have the ability to discretely mine non-standard transactions in their block template, contrary of relay nodes. This observation matters practically e.g w.r.t dust HTLC exposure where miners have an edge 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 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 viewpoint. In my opinion this shall be the responsibility of the Bitcoin Core developers to ensure there is a reasonable safety of the design and implemented mechanism for downstream projects. Experience of the last years, most notably the half of dozen of security weakness loss of funds found in the design or implementation of anchor outputs (the lack of carve out support at first, the revocation escape, the new pinning vector due to legacy merging of second-stage transactions, the parsing error of core lightning / lnd...) can only point out to seasoned technical observers that weakness arises because of the poor understanding of protocols operational inter-dependency. That practical bitcoin experience is matching some observations documented by the IETF in decades of design and development of the TCP / IP stack (RFC 3439) [0]. Under the coupling principle, that as things gets larger, they often exhibit increased inter-dependence between components, and with unforseen feature 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 guard and that all Bitcoin Core devs shall understand downstream protocols as well as the devs who work directly on that protocol does not appear realistic, given the wider variety of other subsystems such as builds, graphic interface or p2p block-relay protocol. _However_, I strongly believe that Bitcoin Core devs working in the subsystem interfacing with downstream protocols such as the mempool or the transaction-relay protocol should have an understood as good as the downstream devs of 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 sense of lack of standing grounded objections, be it by the RBFR author, or 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 for lightning are mostly working for commercial companies, with for some on short business timelines. This is very likely to induce them to pick up an expedient mechanism, 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 Bitcoin Core devs contributors to be immune of short-term external factors in the design of better mempool mechanism as in 2020 while I was advocating to build a better understanding of cross-layers security among contributors [1]. Yet, at the very same time the current author of TRUC and bip331 was doing a round of the medias to "sell" the idea and correspondingly attract open-source funding before there was even the lineaments of a technical consensus among contributors to the Bitcoin Core project, or what you call the downstream devs like lightning [2]. [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002856.html [2] 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 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 the imbuance mechanism, current development process is still on the same pace, heading us in nurturing more cross-layer vectors of attacks like pinning due to complex misinterfacing or mempoolfullrbf 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 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 have a full vanilla configuration on mainnet to avoid running in the myriad of cases with policy standardss and the mempool congestion roallcoaster on whatever is the testnet / signet of the day. I can even put the satosis for funding the channnels if it's really needed. It's correct that TRUC is not implemented in LN in where commitments transactions are nVersion field updated to be pre-signed with TRUC semantics... I can always write a patch in C or rust to have test code ? Though here I would play both the attacker and defender role in the experiment. At least, I think it would be worthwile on its own to test current 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 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. 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 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 > 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. 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-chain 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 the Mallory's package being on an absolute fee / feerate too high to be replaced by a Alice's package. I understand it's hard to understand, and it sounds your attack layout could 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 vector was slightly 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 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 > 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]. 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 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 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. > > 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 correct CPFP to proceed with, the carve-out is ineffective. I'll let you indicate me where in the bolt spec it is indicated how lightning software should implement 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 mechanism has been "fast" shipped in 2019 and that 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 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 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 lightning 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 lightning safety in the past, though after finding vulnerability vectors arising from a policy rule like opt-in RBF and asymmetrically affecting use-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 à 06:48:19 UTC+1, David A. Harding a écrit : > 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/11b7ba56-04f1-4ebe-a434-e8478b5efe70n%40googlegroups.com.