path: root/84/4c6b9776c8f2b1af750f6c88386df3b5d903de

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 <bitcoindev+bncBC3PT7FYWAMRBV5T7O2QMGQEN35NI7A@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <11b7ba56-04f1-4ebe-a434-e8478b5efe70n@googlegroups.com>
In-Reply-To: <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
 <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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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,<br /><br />Apologies for the late answer, I was hiking in nature o=
ver the past few days.<br /><br />&gt; Before I address your full point, I =
think there are two separate things<br />&gt; we want to reason about when =
considering a proposal like TRUC:<br />&gt; <br />&gt; - How does it affect=
 operators of full nodes, including miners and<br />&gt; volunteer relay no=
de operators?<br />&gt; <br />&gt; - How does it affect existing and future=
 protocol users?<br />&gt; <br />&gt; By "easy to reason about", I'm mainly=
 referring to how TRUC will affect<br />&gt; operators of full nodes. IMO, =
it's critical to get that part right. In<br />&gt; comparing TRUC to RBFR, =
it seems to me that it's much easier to reason<br />&gt; about TRUC's effec=
t on relay behavior and mining profitability.<br /><br />I think it's a cor=
rect categorization, with the observation that it can be more<br />interest=
ing to dissociate miners from volunteer relay node operators in the analysi=
s<br />of a proposal like TRUC. Miners have the ability to discretely mine =
non-standard<br />transactions in their block template, contrary of relay n=
odes. This observation<br />matters practically e.g w.r.t dust HTLC exposur=
e where miners have an edge to<br />launch that type of attacks.<br /><br /=
>&gt; When it comes to reasoning about pinning attacks against LN, this is<=
br />&gt; almost fundamentally difficult owing to the difficulty of reasoni=
ng<br />&gt; about any complex state protocol, especially one that interact=
s with<br />&gt; multiple layers of multiple other protocol (e.g., TCP/IP, =
Bitcoin P2P,<br />&gt; Bitcoin consensus). Whether we're talking about CPFP=
, CPFP-CO, opt-in<br />&gt; RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, C=
TV, CAT, TRUC, or<br />&gt; anything else, reasoning about the full implica=
tions of a change for LN<br />&gt; users will be difficult.<br /><br />I do=
n't deny it, with the addition that you have to reason on how the LN<br />g=
ame-theory incentives can play out, in a system where all the balances<br /=
>are denominated in satoshis, a scarce ressource under the max money consen=
sus<br />limit. And I'll keep the conversation simple, as there is always t=
he risk<br />when you're designing second-layers protocol extensions to hav=
e backfire<br />coupling effects on the base-layer (-- one of the main tech=
nical reason<br />we never actually rolled out forward the proof-of-UTXO ow=
nership designed<br />with naumenkogs as a channel jamming mitigation is th=
e base-layer spam<br />risks introduced to bypass it).<br /><br />&gt; IMO,=
 when Bitcoin Core developers ship an opt-in feature like BIP431<br />&gt; =
TRUC, it is not their responsibility to ensure that it is perfectly safe<br=
 />&gt; for downstream projects. That onus falls on the downstream develope=
rs<br />&gt; (e.g., LN devs). Of course, Bitcoin Core devs want to produce =
useful<br />&gt; tools and that incentivizes them to produce actual safety =
improvements;<br />&gt; however, it's unreasonable IMO to expect Bitcoin Co=
re devs to understand<br />&gt; a downstream protocol as well as the devs w=
ho work directly on that<br />&gt; protocol.<br /><br />This is where we ha=
ve a strong divergence, with all my appreciation of your viewpoint.<br /><b=
r />In my opinion this shall be the responsibility of the Bitcoin Core deve=
lopers<br />to ensure there is a reasonable safety of the design and implem=
ented mechanism<br />for downstream projects.<br /><br />Experience of the =
last years, most notably the half of dozen of security weakness<br />loss o=
f funds found in the design or implementation of anchor outputs (the lack o=
f<br />carve out support at first, the revocation escape, the new pinning v=
ector due to<br />legacy merging of second-stage transactions, the parsing =
error of core lightning /<br />lnd...) can only point out to seasoned techn=
ical observers that weakness arises because<br />of the poor understanding =
of protocols operational inter-dependency.<br /><br />That practical bitcoi=
n experience is matching some observations documented by the IETF<br />in d=
ecades of design and development of the TCP / IP stack (RFC 3439) [0]. Unde=
r the coupling<br />principle, that as things gets larger, they often exhib=
it increased inter-dependence between<br />components, and with unforseen f=
eature interaction. In the bitcoin space a good incarnation<br />is all the=
 bip125 rule 3 based economical pinnings, that I don't believe were clearly=
 expected<br />by their bip authors.<br /><br />[0] https://www.rfc-editor.=
org/rfc/rfc3439<br /><br />Obviously, there is a sense of proportion to gua=
rd and that all Bitcoin Core devs<br />shall understand downstream protocol=
s as well as the devs who work directly on that<br />protocol does not appe=
ar realistic, given the wider variety of other subsystems<br />such as buil=
ds, graphic interface or p2p block-relay protocol.<br /><br />_However_, I =
strongly believe that Bitcoin Core devs working in the subsystem<br />inter=
facing with downstream protocols such as the mempool or the transaction-rel=
ay<br />protocol should have an understood as good as the downstream devs o=
f said protocol<br />inner workings. Otherwise, by designing, implementing =
and deploying weak proposals<br />such as TRUC in its earlier versions they=
 might cause more harms than good, on the<br />_long term_.<br /><br />One =
cannot said there was technical consensus with the merge of TRUC, in the se=
nse<br />of lack of standing grounded objections, be it by the RBFR author,=
 or myself directly<br />on the PR / issues implementing this design in Bit=
coin Core.<br /><br />&gt; For something like imbued TRUC, it probably shou=
ldn't be used to replace<br />&gt; an existing mechanism that downstream de=
vs depend on (see subsequent<br />&gt; arguments) unless the downstream dev=
s agree (or there's another very<br />&gt; compelling reason). Again, the o=
nus falls on the downstream developers<br />&gt; to audit the mechanism's s=
afety because they're the ones with<br />&gt; theoretical and operational e=
xperience using the downstream protocol.<br /><br />One should not forget t=
hat downstream protocol devs and contributors e.g for lightning<br />are mo=
stly working for commercial companies, with for some on short business time=
lines.<br />This is very likely to induce them to pick up an expedient mech=
anism, without fully<br />auditing it, more than jeopardizing the end-users=
 funds safety (and the crypto space<br />at large does not miss spectacular=
 vulnerabilities exploitation).<br /><br />Sadly, one cannot expect that Bi=
tcoin Core devs contributors to be immune of short-term<br />external facto=
rs in the design of better mempool mechanism as in 2020 while I was advocat=
ing<br />to build a better understanding of cross-layers security among con=
tributors [1]. Yet,<br />at the very same time the current author of TRUC a=
nd bip331 was doing a round of the<br />medias to "sell" the idea and corre=
spondingly attract open-source funding before there<br />was even the linea=
ments of a technical consensus among contributors to the Bitcoin Core proje=
ct,<br />or what you call the downstream devs like lightning [2].<br /><br =
/>[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-Octobe=
r/002856.html<br />[2] https://bitcoinmagazine.com/technical/gloria-zhao-an=
d-brink-are-set-to-give-bitcoin-mempools-an-upgrade<br /><br />(It's not li=
ke there has been a precedent in bitcoin development with the extension<br =
/>block bip idea from joseph poon...which was proposed in 2017 in a fashion=
 less than usual<br />w.r.t traditional communication channels...)<br /><br=
 />So yes, I think there should be a cultural change in terms of design and=
 deployment<br />of p2p or mempool policy mechanisms supporting downstream =
protocols. In my opinion,<br />which is backed by my first code review of t=
he imbuance mechanism, current development<br />process is still on the sam=
e pace, heading us in nurturing more cross-layer vectors<br />of attacks li=
ke pinning due to complex misinterfacing or mempoolfullrbf default-like<br =
/>difficult campaigns of deprecation.<br /><br />&gt; If you or anoyone thi=
nk TRUC as an alternative to the CPFP as a<br />&gt; transsction pinning mi=
tigation as argued in its merged BIP is easy to<br />&gt; reason on, thanks=
 to communicate your lightning node pubkey, with TRUC<br />&gt; patch appli=
ed and a GPG-signed message authorizing me to demonstrate<br />&gt; the sec=
urity properties of this solutions have not been submitted to a<br />&gt; f=
ully contradictory evaluation.<br /><br />&gt; How would that work? AFAIK, =
there's no LN software using TRUC, very few<br />&gt; relay nodes are using=
 it (since it isn't yet enabled by default in a<br />&gt; release version),=
 and no miners are using it (again, since it hasn't<br />&gt; been released=
). I'm willing to put money at stake to settle a<br />&gt; disagreement tha=
t can't be settled with words, but I want to at least<br />&gt; learn somet=
hing from the process.<br /><br />Thank you for the offer of setting up a d=
emo infrastructure for pinning attacks experiment.<br />I'll describe more =
what is the minimal setup needed in another public email thread<br />or on =
delving bitcoin. Less than the funds in the channel, it's interesting to ha=
ve<br />a full vanilla configuration on mainnet to avoid running in the myr=
iad of cases with<br />policy standardss and the mempool congestion roallco=
aster on whatever is the testnet /<br />signet of the day. I can even put t=
he satosis for funding the channnels if it's really<br />needed.<br /><br /=
>It's correct that TRUC is not implemented in LN in where commitments trans=
actions<br />are nVersion field updated to be pre-signed with TRUC semantic=
s... I can always<br />write a patch in C or rust to have test code ? Thoug=
h here I would play both the<br />attacker and defender role in the experim=
ent. At least, I think it would be worthwile<br />on its own to test curren=
t bip125 rule 3-based economic pinnings, without TRUC usage.<br /><br />&gt=
; My guess is that you're referring to the type of pinning attack you've<br=
 />&gt; called "loophole pinning"[1], which I don't entirely understand, so=
 I'll<br />&gt; do my best to describe it below and hopefully you can corre=
ct me on any<br />&gt; errors:<br />&gt; <br />&gt; - Mallory guesses that,=
 for the next 144 blocks, transactions in the<br />&gt; mempool with a feer=
ate of _x_ sats/vb will neither be confirmed nor<br />&gt; evicted. If Mall=
ory guesses wrong, the attack will fail.<br />&gt; <br />&gt; - Mallory con=
trols a confirmed UTXO that she will spend in 10 different<br />&gt; fee bu=
mping transactions, making all of those transactions conflict.<br />&gt; <b=
r />&gt; - Mallory has 10 channels. It doesn't matter whether these are all=
 with<br />&gt; the same counterparty, different counterparties, or a mix o=
f<br />&gt; counterparties.<br />&gt; <br />&gt; - In each channel:<br />&g=
t; <br />&gt; - Mallory causes the channel to contain the maximum number of=
<br />&gt; in-flight HTLCs the counterparty will allow, creating state _A_.=
<br />&gt; Each in-flight HTLC inflates the size of the commitment transact=
ion<br />&gt; about ~40 vbytes.<br />&gt; <br />&gt; The specification maxi=
mum for in-flight HTLCs is 2*483, but many<br />&gt; implementations defaul=
t to a lower value due to risks from other<br />&gt; known attacks.<br />&g=
t; <br />&gt; - Mallory causes all of the in-flight HTLCs to be settled hon=
estly,<br />&gt; revoking state _A_ that contained them.<br />&gt; <br />&g=
t; - Mallory causes a single HTLC to be sent through the channel. Its<br />=
&gt; satoshi value is chosen to be roughly equal to: x * (vbytes(A) +<br />=
&gt; 1000), where _x_ is Mallory non-confirming-non-expiring feerate,<br />=
&gt; vsize(A) is the size of the revoked commitment transaction, and<br />&=
gt; 1,000 is the maximum size of a TRUC fee-bumping child.<br />&gt; <br />=
&gt; For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC<b=
r />&gt; value is 60,000 sat.<br />&gt; <br />&gt; - Although Mallory knows=
 the preimage necessary to resolve the HTLC,<br />&gt; she doesn't send it =
to her counterparty offchain. This will<br />&gt; eventually force the coun=
terparty to go onchain.<br />&gt; <br />&gt; - Mallory goes onchain first b=
y broadcasting a package that consists<br />&gt; of the revoked state _A_ a=
nd a CPFP fee bump 1,000 vbytes in size<br />&gt; that pays a total fee equ=
al to the pending HTLC value (e.g. 60,000<br />&gt; sat).<br />&gt; <br />&=
gt; - Notably, Mallory is doing this in 10 channels simultaneously with the=
<br />&gt; fee bump for each spending the same UTXO, so all of those fee bu=
mps<br />&gt; conflict with each other. If Mallory broadcasts each package =
of<br />&gt; revoked commitment transaction and fee bump to different nodes=
 across<br />&gt; the network, each particular package will only exist in t=
he mempools<br />&gt; of about 10% of nodes.<br />&gt; <br />&gt; - In some=
 cases, Mallory's channel counterparty will receive the<br />&gt; revoked<b=
r />&gt; commitment transaction via their own mempool monitoring code.<br /=
>&gt; <br />&gt; - If they realize the feerate is below the amount necessar=
y to get<br />&gt; the<br />&gt; transaction confirmed within the next 144 =
blocks, they will be<br />&gt; able<br />&gt; to CPFP fee bump the transact=
ion themselves---but they will need<br />&gt; to pay more than the 60,000 s=
at in fees that Mallory is offering.<br />&gt; However, the pending HTLC is=
 only worth 60,000 sat to them, so it<br />&gt; may not make sense for them=
 to fee bump.<br />&gt; <br />&gt; - In other cases, Mallory's channel coun=
terparty will receive one of<br />&gt; the<br />&gt; conflicting packages. =
They will not know that a revoked commitment<br />&gt; transaction has been=
 broadcast.<br />&gt; <br />&gt; - When Mallory hasn't settled the HTLC fas=
t enough, they will<br />&gt; broadcast a package of their own commitment t=
ransaction and their<br />&gt; own CPFP fee bump child. This will pay a hig=
her feerate than<br />&gt; Mallory paid (which is possible to do under the =
60,000 sat budget<br />&gt; because they're using much smaller transactions=
).<br />&gt; <br />&gt; - Their high feerate package will propagate until i=
t encounters<br />&gt; relay<br />&gt; nodes that have their channel's revo=
ked commitment transaction.<br />&gt; Although the counterparty's transacti=
on pays a higher feerate, it<br />&gt; pays less absolute fees than Mallory=
's transaction and will be<br />&gt; rejected by that relay node.<br />&gt;=
 - In any cases where the pinning prevents confirmation within 144<br />&gt=
; blocks, the HTLC's upstream node can claim a refund and Mallory can<br />=
&gt; then use her preimage to steal the HTLC value from her counterparty,<b=
r />&gt; completing the attack successfully.<br />&gt; <br />&gt; - To sett=
le the HTLC with its preimage, Mallory needs to pay more<br />&gt; absolute=
 fees to remove her pin, but because she pinned 10 channels<br />&gt; with =
a single UTXO, paying to remove the pin from one channel and<br />&gt; gett=
ing that spend confirmed will automatically remove the pin from<br />&gt; a=
ll other channels. In other words, her cost per channel is roughly<br />&gt=
; 10% what her honest counterparties would've had to pay to remove the<br /=
>&gt; pin.<br />&gt; <br />&gt; - However, once Mallory's pin is removed, a=
ll the counterparties<br />&gt; should still broadcast spends of the HTLC-F=
ailure transaction<br />&gt; paying the HTLC's full value to fees in order =
to deprive Mallory<br />&gt; of any profit.<br /><br />The assumption is co=
rrect that Mallory makes a prediction on a level of<br />mempool congestion=
 for a target feerate group, and this is a factor or<br />success or not of=
 the attack.<br /><br />It should be noted, there is no need to revoke the =
state or not in this<br />pinning, one can use the non-revoked consensus va=
lid transaction, I think<br />this is the main difference with my scenario =
where non-revoked transactions<br />are used to do the "staggering" package=
 (i.e the one at 60,000 sat in your<br />example), before to be "unstagged"=
 by the same absolute fee, higher feerate,<br />penalty-paying package.<br =
/><br />The parallelization can allow the attacker to not pay the cost, the=
re is<br />no necessity that it is happening on parallel channels, as one c=
an double-spend<br />from the CPFP of a "batching transaction, whatever els=
e it is doing.<br /><br />&gt; Given the first point and the last point, I'=
m not sure how viable the <br />&gt; attack is (but, as I said, I'm not sur=
e I understand it). Estimating or <br />&gt; manipulating feerates correctl=
y for over 144 blocks in a row sounds <br />&gt; difficult. Counterparties =
being able to deprive Mallory of profit seems <br />&gt; like a major weakn=
ess. <br /><br />On the first point, if I'm understanding correctly it's ab=
out predicting<br />mempool congestion as a factor of success of the attack=
. It's not a perfect<br />art though it's quite practical for an attacker a=
s it is what mempool fee<br />estimation algorithms are all about.<br /><br=
 />On the last point, i.e the HTLC-Failure transaction paying the full valu=
e<br />to the fees, this HTLC-Failure confirmation should happen only after=
 the<br />double-spend of the inbound HTLC by a puppet of Mallory. Until th=
is on-chain<br />confirmation of the malicious inbound HTLC-failure, the Al=
ice's outbound<br />HTLC-failure is blocked by the pinning.<br /><br />Note=
, this is _not_ a replacement cycling attack, as it's all relying on the<br=
 />Mallory's package being on an absolute fee / feerate too high to be repl=
aced<br />by a Alice's package.<br /><br />I understand it's hard to unders=
tand, and it sounds your attack layout could<br />benefit from adding light=
ning topology on the left / right side of Alice as<br />the attack victim. =
Note, how mempool congestion could play as a pinning vector<br />was slight=
ly surveyed in the discussion of package relay design in 2020, though<br />=
no more fleshed-out write-up or blog post has been made available since the=
n until<br />my comment on the Bitcoin Core PR, to the best of my knowledge=
 [4].<br /><br />[4] https://github.com/bitcoin/bitcoin/issues/14895#issuec=
omment-665907792<br /><br />&gt; Looking at other proposed improvements: on=
e-shot RBFR with its <br />&gt; requirement that fee bumps enter the top po=
rtion of the mempool may <br />&gt; avoid this type of pinning; ideas for e=
xpanded versions of TRUC that <br />&gt; also require entering the top port=
ion of the mempool may also avoid this <br />&gt; type of pinning, e.g. "TR=
UC v3.0.5".[2].<br /><br />I have not yet analyzed one-shot RBFR in more de=
tailed, though I believe<br />a better long-term fix is actually _not_ to e=
ntangle the mempool states with<br />transaction-relay propagation rules. A=
 full-node mempoool is a stateful<br />cache with public write allowed.<br =
/><br />&gt; If it looked like RBFR was going to be widely deployed, I thin=
k its<br />&gt; effect on LN would definitely warrant more research.<br /><=
br />If mempool acceptance was more modular in Bitcoin Core, we could have<=
br />more fine-grained transaction acceptance policy module embedded in<br =
/>the `AcceptToMemoryPool` flow and easier to experiment the effects of<br =
/>alternative policy like RBFR on LN.<br /><br />&gt; You described several=
 attacks against anchor outputs using CPFP-CO, some<br />&gt; of which soun=
d quite plausible to me, but none of them is certain to<br />&gt; succeed i=
n any particular instance. By comparison, disabling CPFP-CO<br />&gt; would=
 leave all users of anchor outputs immediately vulnerable to the<br />&gt; =
original pinning attack that has an expected ~100% success rate and<br />&g=
t; barely any cost if executed against multiple channels simultaneously.<br=
 />&gt; <br />&gt; Given that, it makes no sense to disable CPFP-CO until a=
 successor is<br />&gt; available.<br /><br />In a world where revoked ligh=
tning transactions are still consensus-valid<br />and where any of them can=
 be used to blind the lightning node of the correct<br />CPFP to proceed wi=
th, the carve-out is ineffective.<br /><br />I'll let you indicate me where=
 in the bolt spec it is indicated how lightning<br />software should implem=
ent correctly CPFP of the carve-out, as it is implemented<br />and deployed=
 in Bitcoin Core since circa 2019.<br /><br />I won't say the carve-out mec=
hanism has been "fast" shipped in 2019 and that<br />its authors might real=
ly not know how lightnning was working at the time.<br />However, I believe=
 there has never been a bip or other document informing how it<br />should =
be used by downtream protocols.<br /><br />&gt; Thank you for your opinion.=
 I too think TRUC is a good solution until<br />&gt; we find something bett=
er, and any significant improvements may indeed<br />&gt; require consensus=
 changes.<br /><br />Thank too for your opinion. I think TRUC is an accepta=
ble temporary solution<br />to minimize lightning pinning surface, however =
I'm still worried on the long-term<br />it can have undesirable side-effect=
, in a world where miners are running "heretic"<br />transaction acceptance=
 policy.<br /><br />And it's making a false security guarantee for lightnin=
g nodes, as uniform policy<br />is not a network reality, and an associated=
 full-node could be paired with peers<br />not respecting TRUC semantics --=
 I know I've advocated uniform policy w.r.t package relay<div>to improve li=
ghtning safety in the past, though after finding vulnerability vectors aris=
ing<br />from a policy rule like opt-in RBF and asymmetrically affecting us=
e-cases (0conf vs LN), I'm<br />far more skeptical in grounding downstream =
protocols safety on mechanism like TRUC.<br /><br />Best,<br />Antoine<br /=
>ots hash: 42407994c5e58123bf2535ba420517f83b95977052b4bde4ff9e115b91e2b598=
<br /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gma=
il_attr">Le mardi 30 juillet 2024 =C3=A0 06:48:19 UTC+1, David A. Harding a=
 =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: =
1ex;">On 2024-07-20 16:10, Antoine Riard wrote:
<br>&gt; If you or anoyone think TRUC as an alternative to the CPFP as a
<br>&gt; transaction pinning mitigation as argued in its merged BIP is easy=
 to
<br>&gt; reason on [...]
<br>
<br>Before I address your full point, I think there are two separate things
<br>we want to reason about when considering a proposal like TRUC:
<br>
<br>- How does it affect operators of full nodes, including miners and
<br>   volunteer relay node operators?
<br>
<br>- How does it affect existing and future protocol users?
<br>
<br>By &quot;easy to reason about&quot;, I&#39;m mainly referring to how TR=
UC will affect
<br>operators of full nodes.  IMO, it&#39;s critical to get that part right=
.  In
<br>comparing TRUC to RBFR, it seems to me that it&#39;s much easier to rea=
son
<br>about TRUC&#39;s effect on relay behavior and mining profitability.
<br>
<br>When it comes to reasoning about pinning attacks against LN, this is
<br>almost fundamentally difficult owing to the difficulty of reasoning
<br>about any complex state protocol, especially one that interacts with
<br>multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P,
<br>Bitcoin consensus).  Whether we&#39;re talking about CPFP, CPFP-CO, opt=
-in
<br>RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or
<br>anything else, reasoning about the full implications of a change for LN
<br>users will be difficult.
<br>
<br>IMO, when Bitcoin Core developers ship an opt-in feature like BIP431
<br>TRUC, it is not their responsibility to ensure that it is perfectly saf=
e
<br>for downstream projects.  That onus falls on the downstream developers
<br>(e.g., LN devs).  Of course, Bitcoin Core devs want to produce useful
<br>tools and that incentivizes them to produce actual safety improvements;
<br>however, it&#39;s unreasonable IMO to expect Bitcoin Core devs to under=
stand
<br>a downstream protocol as well as the devs who work directly on that
<br>protocol.
<br>
<br>For something like imbued TRUC, it probably shouldn&#39;t be used to re=
place
<br>an existing mechanism that downstream devs depend on (see subsequent
<br>arguments) unless the downstream devs agree (or there&#39;s another ver=
y
<br>compelling reason).  Again, the onus falls on the downstream developers
<br>to audit the mechanism&#39;s safety because they&#39;re the ones with
<br>theoretical and operational experience using the downstream protocol.
<br>
<br>Now on to your full point:
<br>
<br>&gt; If you or anoyone think TRUC as an alternative to the CPFP as a
<br>&gt; transsction pinning mitigation as argued in its merged BIP is easy=
 to
<br>&gt; reason on, thanks to communicate your lightning node pubkey, with =
TRUC
<br>&gt; patch applied and a GPG-signed message authorizing me to demonstra=
te
<br>&gt; the security properties of this solutions have not been submitted =
to a
<br>&gt; fully contradictory evaluation.
<br>
<br>How would that work?  AFAIK, there&#39;s no LN software using TRUC, ver=
y few
<br>relay nodes are using it (since it isn&#39;t yet enabled by default in =
a
<br>release version), and no miners are using it (again, since it hasn&#39;=
t
<br>been released).  I&#39;m willing to put money at stake to settle a
<br>disagreement that can&#39;t be settled with words, but I want to at lea=
st
<br>learn something from the process.
<br>
<br>My guess is that you&#39;re referring to the type of pinning attack you=
&#39;ve
<br>called &quot;loophole pinning&quot;[1], which I don&#39;t entirely unde=
rstand, so I&#39;ll
<br>do my best to describe it below and hopefully you can correct me on any
<br>errors:
<br>
<br>- Mallory guesses that, for the next 144 blocks, transactions in the
<br>   mempool with a feerate of _x_ sats/vb will neither be confirmed nor
<br>   evicted.  If Mallory guesses wrong, the attack will fail.
<br>
<br>- Mallory controls a confirmed UTXO that she will spend in 10 different
<br>   fee bumping transactions, making all of those transactions conflict.
<br>
<br>- Mallory has 10 channels.  It doesn&#39;t matter whether these are all=
 with
<br>   the same counterparty, different counterparties, or a mix of
<br>   counterparties.
<br>
<br>- In each channel:
<br>
<br>   - Mallory causes the channel to contain the maximum number of
<br>     in-flight HTLCs the counterparty will allow, creating state _A_.
<br>     Each in-flight HTLC inflates the size of the commitment transactio=
n
<br>     about ~40 vbytes.
<br>
<br>     The specification maximum for in-flight HTLCs is 2*483, but many
<br>     implementations default to a lower value due to risks from other
<br>     known attacks.
<br>
<br>   - Mallory causes all of the in-flight HTLCs to be settled honestly,
<br>     revoking state _A_ that contained them.
<br>
<br>   - Mallory causes a single HTLC to be sent through the channel.  Its
<br>     satoshi value is chosen to be roughly equal to: x * (vbytes(A) +
<br>     1000), where _x_ is Mallory non-confirming-non-expiring feerate,
<br>     vsize(A) is the size of the revoked commitment transaction, and
<br>     1,000 is the maximum size of a TRUC fee-bumping child.
<br>
<br>     For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HT=
LC
<br>     value is 60,000 sat.
<br>
<br>   - Although Mallory knows the preimage necessary to resolve the HTLC,
<br>     she doesn&#39;t send it to her counterparty offchain.  This will
<br>     eventually force the counterparty to go onchain.
<br>
<br>   - Mallory goes onchain first by broadcasting a package that consists
<br>     of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size
<br>     that pays a total fee equal to the pending HTLC value (e.g. 60,000
<br>     sat).
<br>
<br>- Notably, Mallory is doing this in 10 channels simultaneously with the
<br>   fee bump for each spending the same UTXO, so all of those fee bumps
<br>   conflict with each other.  If Mallory broadcasts each package of
<br>   revoked commitment transaction and fee bump to different nodes acros=
s
<br>   the network, each particular package will only exist in the mempools
<br>   of about 10% of nodes.
<br>
<br>   - In some cases, Mallory&#39;s channel counterparty will receive the=
=20
<br>revoked
<br>     commitment transaction via their own mempool monitoring code.
<br>
<br>     - If they realize the feerate is below the amount necessary to get=
=20
<br>the
<br>       transaction confirmed within the next 144 blocks, they will be=
=20
<br>able
<br>       to CPFP fee bump the transaction themselves---but they will need
<br>       to pay more than the 60,000 sat in fees that Mallory is offering=
.
<br>       However, the pending HTLC is only worth 60,000 sat to them, so i=
t
<br>       may not make sense for them to fee bump.
<br>
<br>   - In other cases, Mallory&#39;s channel counterparty will receive on=
e of=20
<br>the
<br>     conflicting packages.  They will not know that a revoked commitmen=
t
<br>     transaction has been broadcast.
<br>
<br>     - When Mallory hasn&#39;t settled the HTLC fast enough, they will
<br>       broadcast a package of their own commitment transaction and thei=
r
<br>       own CPFP fee bump child.  This will pay a higher feerate than
<br>       Mallory paid (which is possible to do under the 60,000 sat budge=
t
<br>       because they&#39;re using much smaller transactions).
<br>
<br>     - Their high feerate package will propagate until it encounters=20
<br>relay
<br>       nodes that have their channel&#39;s revoked commitment transacti=
on.
<br>       Although the counterparty&#39;s transaction pays a higher feerat=
e, it
<br>       pays less absolute fees than Mallory&#39;s transaction and will =
be
<br>       rejected by that relay node.
<br>
<br>- In any cases where the pinning prevents confirmation within 144
<br>   blocks, the HTLC&#39;s upstream node can claim a refund and Mallory =
can
<br>   then use her preimage to steal the HTLC value from her counterparty,
<br>   completing the attack successfully.
<br>
<br>   - To settle the HTLC with its preimage, Mallory needs to pay more
<br>     absolute fees to remove her pin, but because she pinned 10 channel=
s
<br>     with a single UTXO, paying to remove the pin from one channel and
<br>     getting that spend confirmed will automatically remove the pin fro=
m
<br>     all other channels.  In other words, her cost per channel is rough=
ly
<br>     10% what her honest counterparties would&#39;ve had to pay to remo=
ve the
<br>     pin.
<br>
<br>     - However, once Mallory&#39;s pin is removed, all the counterparti=
es
<br>       should still broadcast spends of the HTLC-Failure transaction
<br>       paying the HTLC&#39;s full value to fees in order to deprive Mal=
lory
<br>       of any profit.
<br>
<br>Given the first point and the last point, I&#39;m not sure how viable t=
he
<br>attack is (but, as I said, I&#39;m not sure I understand it).  Estimati=
ng or
<br>manipulating feerates correctly for over 144 blocks in a row sounds
<br>difficult.  Counterparties being able to deprive Mallory of profit seem=
s
<br>like a major weakness.
<br>
<br>Looking at other proposed improvements: one-shot RBFR with its
<br>requirement that fee bumps enter the top portion of the mempool may
<br>avoid this type of pinning; ideas for expanded versions of TRUC that
<br>also require entering the top portion of the mempool may also avoid thi=
s
<br>type of pinning, e.g. &quot;TRUC v3.0.5&quot;.[2]
<br>
<br>&gt; About replace-by-feerate, I think it&#39;s a solution that have do=
wnside
<br>&gt; on its own, especially for second-layers like lightning.
<br>
<br>If it looked like RBFR was going to be widely deployed, I think its
<br>effect on LN would definitely warrant more research.
<br>
<br>&gt; And as I observed on one of the V3 PR threads and corresponding
<br>&gt; conversations, the CPFP carve-out do not provide
<br>&gt; security to lightning implementation
<br>&gt; [...]
<br>&gt; So unless someone argued to the contrary, saying TRUC was needed t=
o
<br>&gt; then deploy cluster mempool is an intellectual fallacy
<br>
<br>You described several attacks against anchor outputs using CPFP-CO, som=
e
<br>of which sound quite plausible to me, but none of them is certain to
<br>succeed in any particular instance.  By comparison, disabling CPFP-CO
<br>would leave all users of anchor outputs immediately vulnerable to the
<br>original pinning attack that has an expected ~100% success rate and
<br>barely any cost if executed against multiple channels simultaneously.
<br>
<br>Given that, it makes no sense to disable CPFP-CO until a successor is
<br>available.
<br>
<br>&gt; On my personal perspective, and after careful considerations of al=
l
<br>&gt; the technical points you&#39;ve raised. I still think TRUC has a l=
ot of
<br>&gt; problems. RBRFr too has technical problems. About TRUC I think it&=
#39;s an
<br>&gt; acceptable temporary solution to minimize the pinning surface of
<br>&gt; lightning implementations, pending for the design of a better solu=
tion
<br>&gt; (more likely at the consensus-level [...])
<br>
<br>Thank you for your opinion.  I too think TRUC is a good solution until
<br>we find something better, and any significant improvements may indeed
<br>require consensus changes.
<br>
<br>-Dave
<br>
<br>[1]=20
<br><a href=3D"https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1=
888377830" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bitcoin/pu=
ll/28948%23issuecomment-1888377830&amp;source=3Dgmail&amp;ust=3D17238677570=
05000&amp;usg=3DAOvVaw1HpBlxseyf2-uuuMYpkR-R">https://github.com/bitcoin/bi=
tcoin/pull/28948#issuecomment-1888377830</a>
<br>[2] <a href=3D"https://delvingbitcoin.org/t/v3-and-some-possible-future=
s/523" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://w=
ww.google.com/url?hl=3Dfr&amp;q=3Dhttps://delvingbitcoin.org/t/v3-and-some-=
possible-futures/523&amp;source=3Dgmail&amp;ust=3D1723867757005000&amp;usg=
=3DAOvVaw1TIwDUN31wZ1gfV_l6iQhN">https://delvingbitcoin.org/t/v3-and-some-p=
ossible-futures/523</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/11b7ba56-04f1-4ebe-a434-e8478b5efe70n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/11b7ba56-04f1-4ebe-a434-e8478b5efe70n%40googlegroups.com</a>.=
<br />

------=_Part_25719_1015100085.1723782038417--

------=_Part_25718_869047551.1723782038417--