Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 30910 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 34907 bytes --]