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

["David A. Harding" <dave@dtrt.org>]

On 2024-07-20 16:10, Antoine Riard wrote:
> If you or anoyone think TRUC as an alternative to the CPFP as a
> transaction pinning mitigation as argued in its merged BIP is easy to
> reason on [...]

Before I address your full point, I think there are two separate things
we want to reason about when considering a proposal like TRUC:

- How does it affect operators of full nodes, including miners and
   volunteer relay node operators?

- How does it affect existing and future protocol users?

By "easy to reason about", I'm mainly referring to how TRUC will affect
operators of full nodes.  IMO, it's critical to get that part right.  In
comparing TRUC to RBFR, it seems to me that it's much easier to reason
about TRUC's effect on relay behavior and mining profitability.

When it comes to reasoning about pinning attacks against LN, this is
almost fundamentally difficult owing to the difficulty of reasoning
about any complex state protocol, especially one that interacts with
multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P,
Bitcoin consensus).  Whether we're talking about CPFP, CPFP-CO, opt-in
RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or
anything else, reasoning about the full implications of a change for LN
users will be difficult.

IMO, when Bitcoin Core developers ship an opt-in feature like BIP431
TRUC, it is not their responsibility to ensure that it is perfectly safe
for downstream projects.  That onus falls on the downstream developers
(e.g., LN devs).  Of course, Bitcoin Core devs want to produce useful
tools and that incentivizes them to produce actual safety improvements;
however, it's unreasonable IMO to expect Bitcoin Core devs to understand
a downstream protocol as well as the devs who work directly on that
protocol.

For something like imbued TRUC, it probably shouldn't be used to replace
an existing mechanism that downstream devs depend on (see subsequent
arguments) unless the downstream devs agree (or there's another very
compelling reason).  Again, the onus falls on the downstream developers
to audit the mechanism's safety because they're the ones with
theoretical and operational experience using the downstream protocol.

Now on to your full point:

> If you or anoyone think TRUC as an alternative to the CPFP as a
> transsction pinning mitigation as argued in its merged BIP is easy to
> reason on, thanks to communicate your lightning node pubkey, with TRUC
> patch applied and a GPG-signed message authorizing me to demonstrate
> the security properties of this solutions have not been submitted to a
> fully contradictory evaluation.

How would that work?  AFAIK, there's no LN software using TRUC, very few
relay nodes are using it (since it isn't yet enabled by default in a
release version), and no miners are using it (again, since it hasn't
been released).  I'm willing to put money at stake to settle a
disagreement that can't be settled with words, but I want to at least
learn something from the process.

My guess is that you're referring to the type of pinning attack you've
called "loophole pinning"[1], which I don't entirely understand, so I'll
do my best to describe it below and hopefully you can correct me on any
errors:

- Mallory guesses that, for the next 144 blocks, transactions in the
   mempool with a feerate of _x_ sats/vb will neither be confirmed nor
   evicted.  If Mallory guesses wrong, the attack will fail.

- Mallory controls a confirmed UTXO that she will spend in 10 different
   fee bumping transactions, making all of those transactions conflict.

- Mallory has 10 channels.  It doesn't matter whether these are all with
   the same counterparty, different counterparties, or a mix of
   counterparties.

- In each channel:

   - Mallory causes the channel to contain the maximum number of
     in-flight HTLCs the counterparty will allow, creating state _A_.
     Each in-flight HTLC inflates the size of the commitment transaction
     about ~40 vbytes.

     The specification maximum for in-flight HTLCs is 2*483, but many
     implementations default to a lower value due to risks from other
     known attacks.

   - Mallory causes all of the in-flight HTLCs to be settled honestly,
     revoking state _A_ that contained them.

   - Mallory causes a single HTLC to be sent through the channel.  Its
     satoshi value is chosen to be roughly equal to: x * (vbytes(A) +
     1000), where _x_ is Mallory non-confirming-non-expiring feerate,
     vsize(A) is the size of the revoked commitment transaction, and
     1,000 is the maximum size of a TRUC fee-bumping child.

     For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC
     value is 60,000 sat.

   - Although Mallory knows the preimage necessary to resolve the HTLC,
     she doesn't send it to her counterparty offchain.  This will
     eventually force the counterparty to go onchain.

   - Mallory goes onchain first by broadcasting a package that consists
     of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size
     that pays a total fee equal to the pending HTLC value (e.g. 60,000
     sat).

- Notably, Mallory is doing this in 10 channels simultaneously with the
   fee bump for each spending the same UTXO, so all of those fee bumps
   conflict with each other.  If Mallory broadcasts each package of
   revoked commitment transaction and fee bump to different nodes across
   the network, each particular package will only exist in the mempools
   of about 10% of nodes.

   - In some cases, Mallory's channel counterparty will receive the 
revoked
     commitment transaction via their own mempool monitoring code.

     - If they realize the feerate is below the amount necessary to get 
the
       transaction confirmed within the next 144 blocks, they will be 
able
       to CPFP fee bump the transaction themselves---but they will need
       to pay more than the 60,000 sat in fees that Mallory is offering.
       However, the pending HTLC is only worth 60,000 sat to them, so it
       may not make sense for them to fee bump.

   - In other cases, Mallory's channel counterparty will receive one of 
the
     conflicting packages.  They will not know that a revoked commitment
     transaction has been broadcast.

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

     - Their high feerate package will propagate until it encounters 
relay
       nodes that have their channel's revoked commitment transaction.
       Although the counterparty's transaction pays a higher feerate, it
       pays less absolute fees than Mallory's transaction and will be
       rejected by that relay node.

- In any cases where the pinning prevents confirmation within 144
   blocks, the HTLC's upstream node can claim a refund and Mallory can
   then use her preimage to steal the HTLC value from her counterparty,
   completing the attack successfully.

   - To settle the HTLC with its preimage, Mallory needs to pay more
     absolute fees to remove her pin, but because she pinned 10 channels
     with a single UTXO, paying to remove the pin from one channel and
     getting that spend confirmed will automatically remove the pin from
     all other channels.  In other words, her cost per channel is roughly
     10% what her honest counterparties would've had to pay to remove the
     pin.

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

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

Looking at other proposed improvements: one-shot RBFR with its
requirement that fee bumps enter the top portion of the mempool may
avoid this type of pinning; ideas for expanded versions of TRUC that
also require entering the top portion of the mempool may also avoid this
type of pinning, e.g. "TRUC v3.0.5".[2]

> About replace-by-feerate, I think it's a solution that have downside
> on its own, especially for second-layers like lightning.

If it looked like RBFR was going to be widely deployed, I think its
effect on LN would definitely warrant more research.

> And as I observed on one of the V3 PR threads and corresponding
> conversations, the CPFP carve-out do not provide
> security to lightning implementation
> [...]
> So unless someone argued to the contrary, saying TRUC was needed to
> then deploy cluster mempool is an intellectual fallacy

You described several attacks against anchor outputs using CPFP-CO, some
of which sound quite plausible to me, but none of them is certain to
succeed in any particular instance.  By comparison, disabling CPFP-CO
would leave all users of anchor outputs immediately vulnerable to the
original pinning attack that has an expected ~100% success rate and
barely any cost if executed against multiple channels simultaneously.

Given that, it makes no sense to disable CPFP-CO until a successor is
available.

> On my personal perspective, and after careful considerations of all
> the technical points you've raised. I still think TRUC has a lot of
> problems. RBRFr too has technical problems. About TRUC I think it's an
> acceptable temporary solution to minimize the pinning surface of
> lightning implementations, pending for the design of a better solution
> (more likely at the consensus-level [...])

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

-Dave

[1] 
https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1888377830
[2] https://delvingbitcoin.org/t/v3-and-some-possible-futures/523

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/4e959cdbe70b1a3b9f1adb37fe3b986e%40dtrt.org.