path: root/4f/cd81d3fbf25a2571b51eba2221cea7238279cd

Delivery-date: Thu, 05 Dec 2024 13:35:34 -0800
Received: from mail-qv1-f59.google.com ([209.85.219.59])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBG5ZZC5AMGQETW72LNQ@googlegroups.com>)
	id 1tJJVT-0005DO-Mx
	for bitcoindev@gnusha.org; Thu, 05 Dec 2024 13:35:33 -0800
Received: by mail-qv1-f59.google.com with SMTP id 6a1803df08f44-6d889fd0fd6sf27539396d6.0
        for <bitcoindev@gnusha.org>; Thu, 05 Dec 2024 13:35:31 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1733434525; cv=pass;
        d=google.com; s=arc-20240605;
        b=FAicWo6P6DonYRBCyi3z5XEbklhiImQP2RgQCn7hvrG74DcAAlL0FydhyWqJNNjvhJ
         GsQlwdB9NECxXe6bfaez5+Emzp5GktD28RKKnHPHYZ23yWGsY6nMCfbvbrOJ697jq3HN
         v9bgoKY22qYxd7zSHMH07JCpi8AJJ+ljhpRHxlJKbx40j7pt4Pz5LptLSokuchSOdH6W
         zbv0PGGBgT73cWN4h5Y1pfR8HlW0IfOjpq07TxvclfQS2LnmHFg4W8whtE1RJ4tJD9LX
         cSqCQABqgW922PZO5cfDpDuSJldmJ29QmSE7MbXyL/hVAW+ZrmFl9cyaLcTmMSv82b1g
         kx5A==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :mime-version:sender:dkim-signature:dkim-signature;
        bh=X7iFSx7FbJ+f0QWTlmYPLOP4ltljLAn0dkzr42vKzoM=;
        fh=3w35+q5QcKS7tCQy6bo8Q64yNGdiMQqU3qyDallT1Jk=;
        b=Pm1wegvISFBQ1Z55DpPg8rDIEGt4XwmpLPhMPa/NwYGDT5wNED/SaylPusSq0fhwvN
         6erlftmTs4HqNlIMEQCXjvlN6ORujPJzO780L8NNwmDzF8LgF1YqcRdCLZAkjNODy9ID
         csYJmIxEZeyuWb4XOJIB3yOWCSLRfRtXhD5F4Ga49WGQ5oE+A32Aje3amnex219/Y1nq
         kQb5WLz4gCgiaR9+81NpIveMXfD0Ld/TIwriZFpn0dxE88Lv+QWq9S9jFREJgnx7pVTI
         WlwPVX7SvveLSGNJ/EbesJLpnzWrD4u5I2c77lp3L7bwxkHcpXDWAVzHoaKafoQXagUY
         Gojg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=JLZrfgeq;
       spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1733434525; x=1734039325; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:mime-version
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=X7iFSx7FbJ+f0QWTlmYPLOP4ltljLAn0dkzr42vKzoM=;
        b=vopBLquMl8kTuv6ubWJjXEiDwlIQdck+MF9u/9ptAITgs6w+dR3IgyVp4yROcdn9Fh
         pgH4n0L1x98n7Skfer8P3hOEQChjzkWo08V1rig8ZPROKuQqptVp9KVaOjaLZ6UNoE/D
         XAjYd00VKBOI/zufnKJl6sxd//NnTMmgF4aehEjESi1V/jDsQaDjcX3i7VaWZ8E/c+Dd
         GDyr3JcGfXvhI4oXgMRPG8xefDWepfULQg1rCe5PvPCloooRcNeJO/ompf2pgOKe+06A
         OamGaSeShZ+uHynUqnZcKd3kGI5dvmfQ4NyeuOWwdSKOLRnXjGhC3va7ogMfYLVjvYqH
         R/rw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733434525; x=1734039325; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:mime-version
         :from:to:cc:subject:date:message-id:reply-to;
        bh=X7iFSx7FbJ+f0QWTlmYPLOP4ltljLAn0dkzr42vKzoM=;
        b=Sthm4a6uZwFW6WG3lSgJ8TATUea7LJgjTE6Kxg9nhdBAgWGZODHEALKhi0rI6JYJq2
         ie76l/PYwh0T8LlmZfM44u38VNwxfsupAVOKgXqAkSjkJzaV3Zy1j+LQjjjxyZ5cLsOG
         gOTyUZwaWGwUld7YrdZUkYRkn//K+JjaHgdfhZT3PBjmfCBcet3MraiEkwTHW5R2zZnv
         +jzhUcrQ6skG56kW1WIzYFVPMGpULs/auveA0G+GscA4VnusPQQ6waTTWgpnIPPpz9np
         GPPPn4mMqSzeCv/x21iZPtsh6oZ+IhS12jmdcHd0+SmmmdwqD47D6KkpML7ClkzqB7tS
         VoJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733434525; x=1734039325;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:mime-version
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=X7iFSx7FbJ+f0QWTlmYPLOP4ltljLAn0dkzr42vKzoM=;
        b=rjEhrnIakfZ2QKj1jCKfxhY2W132S2klnldU/yawlhIhSHB0SYar0XRRIojscNtgTA
         GBYyGprJvu4xTtZAc6RQinS9rrEv63CypX+oCt1fks6fnbs4G/Zg+W9X8ln/tCUrGl4k
         7JdnMQ4flI7bMbYhfxAtBpn2wDNbPaMaezJ+UyiscBB718bQ0ZwOiXAZgm2EEhLvVU5h
         dvyHEtX0LiaVls2X2yYbpDr1WrmsyP9aHHaxp1RXrPxR4FY3YPe8U2RjheqV1bHnxsY2
         Mj0xmcySH4ANYp0HcE8fNR8htaG+KSSm/GX0IgbZs6o/aY2rgf+SaArYl9gqkCVRBM8G
         K1Wg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVVNHAtoGhYTDNCIEA2kR8GWdM6z708PUaCOQbZXypTdZa++jCEbnllWSWT6oO/kyxuyYE0fCN22Uqz@gnusha.org
X-Gm-Message-State: AOJu0YwsgUbpvRmBoUm5CgzYTVWx+MMMY78+JXkhRftZrgUMnoMkTeUQ
	wy5X8KDa6mG2ZWMJxrVtc5E4TFg2+BiK8jkCggx6GmSAKSkbEq/y
X-Google-Smtp-Source: AGHT+IF0EoyfaFSdjwqow6CLgnM7Xj2cIMOZtywah9YSOMc9XRZagqaUnevoD8eezI/i05rqHJvS3w==
X-Received: by 2002:a05:6214:240f:b0:6d8:88c2:af5f with SMTP id 6a1803df08f44-6d8e645db3emr13393846d6.1.1733434525445;
        Thu, 05 Dec 2024 13:35:25 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:ad4:5f8f:0:b0:6d8:87d5:f981 with SMTP id 6a1803df08f44-6d8d6fd80e1ls23616706d6.2.-pod-prod-00-us;
 Thu, 05 Dec 2024 13:35:23 -0800 (PST)
X-Received: by 2002:a05:620a:17a0:b0:7b1:7508:9f38 with SMTP id af79cd13be357-7b6b4187b0cmr741672285a.16.1733434523003;
        Thu, 05 Dec 2024 13:35:23 -0800 (PST)
Received: by 2002:a05:620a:11a5:b0:7b1:452e:2a50 with SMTP id af79cd13be357-7b6b54cc47bms85a;
        Thu, 5 Dec 2024 09:48:30 -0800 (PST)
X-Received: by 2002:a05:6102:50ab:b0:4af:57df:8697 with SMTP id ada2fe7eead31-4afb9607a5fmr5586722137.10.1733420909276;
        Thu, 05 Dec 2024 09:48:29 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1733420909; cv=none;
        d=google.com; s=arc-20240605;
        b=ZDHXQMnDL2sfc4ZHFCxmKv8zBRotOSEeKHP1Oej5CqzICkHCZqecMo83el5v8lg9jN
         kr/CYRDhIC/ilo/pOhX7CP3FayT2hg87Vst4XqH2J3JUsRPORO2dshkfOu/dwNYO5qw7
         XYjiXtExaEjS0m12vUkBS4M/FmJC1EKjLOVEDLtQgdptJUOHxLyfekeu3w7ML4UKetf+
         8wyLHK3wcE3VNHmkfEQX922tceGqYxN1KIRp4Si71uYJVjTZ5vgy/DbKU6t2QMMSfc+0
         KBIByVSklqwQezpsRcpgKGypsYU6JRlHmOsZFv2ziTn3n7vGSUSg8JKxdYn0QCoekj4j
         o2iw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:mime-version:dkim-signature;
        bh=Sd42RirJ6F5rUZ7S9yWFFKu/V0VwokigW4pQiFRdmi0=;
        fh=TrDDrH77hhIgp0mK2MdRvoco8jyXYiElDX5vXgyPiMs=;
        b=fNqinIh/oCVLOKESRbuGnMJHxvnyoDU7a/tdylEMboKCI1G3vPD1qp0XnkfCITPkaR
         gzTOI3IQCVAyTslL2vYjko6HyeGOlTK5nqvqENHMbErDo4JRAiLXRDfjSMrGe/Fz7LEE
         vebFz8pnx6nBtJvNQZfsYDYHznaYwifaaWZHK1dZ++RSu64GgLfooKAgfCmcI8H7gajv
         BCoGv/G/3J/9vqBTBJ8buAUZvg4aLWdUjpWvj3knPdInVnt+DntNsdIOGFcSiRAcnygD
         H69AYFEfshNT42kdhULJOVGbyeX+rJNl9B8rZOlohqo9BL/3XqtW4erjie0bD2Ej5iup
         V6vw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=JLZrfgeq;
       spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com. [2607:f8b0:4864:20::102f])
        by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-85c2bc8f161si66073241.1.2024.12.05.09.48.29
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 05 Dec 2024 09:48:29 -0800 (PST)
Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) client-ip=2607:f8b0:4864:20::102f;
Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2ee76929a98so1005610a91.1
        for <bitcoindev@googlegroups.com>; Thu, 05 Dec 2024 09:48:29 -0800 (PST)
X-Gm-Gg: ASbGnct83hs/plJuexUVYqH/rU5Lw56cC05EjbPNDbG4KSBZURMfep+G61bIisicagE
	rqy5/rxn+gRw5zcVvh/qwUWibwg22CjEl
X-Received: by 2002:a17:90a:c10f:b0:2ee:ee77:226d with SMTP id
 98e67ed59e1d1-2ef68c88eebmr316691a91.4.1733420907434; Thu, 05 Dec 2024
 09:48:27 -0800 (PST)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 5 Dec 2024 17:48:16 +0000
Message-ID: <CALZpt+EptER=p+P7VN3QAb9n=dODA9_LnR9xZwWpRsdAwedv=w@mail.gmail.com>
Subject: [bitcoindev] Full Disclosure: "Transaction-Relay Throughput Overflow
 Attacks against Off-Chain Protocols"
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: security@ariard.me
Content-Type: multipart/alternative; boundary="0000000000006f1b6a062889811f"
X-Original-Sender: antoine.riard@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=JLZrfgeq;       spf=pass
 (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::102f
 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.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 (/)

--0000000000006f1b6a062889811f
Content-Type: text/plain; charset="UTF-8"

Hi all,

I'm writing a report to disclose a new transaction-relay jamming attack
affecting bitcoin time-sensitive contracting protocols by exploiting the
transaction
selection, announcement and propagation mechanisms of base-layer full-nodes.

Back in 2020, amid numerous technical conversations among bitcoin protocol
developers
about how bip125 replace-by-fee rules could be abused by a lightning
channel counterparty
with a competing interest (a.k.a pinning attack, see BIP431's motivation
for more), it
was thought that few other components of the bitcoin tx-relay p2p stack
could be also
adversarially exploited [0] (In the lack of familiarity with lightning /
contracting
protocol security risks, go to read the old post pointed by footnote).

Mid-2023, I did privately message a group of long-term bitcoin and lightning
developers detailing those new "transaction-relay throughput attacks"
concerns,
especially the different exploitations and the technical feasibility of
such attack.

While this attack was deemed worthy of more investigations and practical
testing, it
was relatively put in the background due to more severe security issues
affecting
lightning at the time (i.e 2023). Recent conversations this year (i.e 2024)
about
free relay attacks of full-node bandwidths made me think to reconsider the
practical
cost of transaction-relay throughput attacks, and as such proceeds to a
full disclosure.

Since my personal awareness in 2020 of this potential vector of attack
enabling to
steal funds from lightning channel funds, I've not seen exploitations in
the wild or
corresponding hints that could reveal such new transaction-relay jamming
attack
being practically used.

In this report, 2 variations of those new "transaction-relay throughput
attacks"
are presented, i.e respectively the "high overflow" and the "low overflow"
variant.
There is a proof-of-concept available for the "high overflow" variation
tested on
bitcoin core v27.0. The "high overflow" variation has been tested under few
topological
configurations, though no under real-world workload. Coming with a
proof-of-concept
to demonstrate the feasibility of the 2nd variation stays an open subject
of investigation.
(see corresponding subsection for more).

After conversation with few lightning maintainers, it arises as a main
conclusion
that currently deployed random rebroadcast of time-sensitive transactions
was probably
one of the most effective mitigation that could be solely deployed by
lightning
implementation themselves. In this report, 2 variations of those new
"transaction-relay
throughput attacks" are presented, i.e respectively the "high overflow" and
"low overflow"
variants.

At the time of writing, the "high overflow" attack cost is evaluated to be
around
$80k to target real-world lightning channels with safety timelocks in the
the order
of four dozen of blocks.

In my reasonable opinion, I believe this new transaction-relay jamming
attack can
be as much severe than already known state of the art non-mitigated attacks
against
lightning channels while minding the junk transaction traffic cost. However
more
investigations of this transaction-relay throughput attack vector can be
very valuable.

This new off-chain protocol attack vector is currently tracked by the CVE
Request 1780258 shared to the MITRE, under a single identifier for a
"multiple
software, same protocol / attack vector". Report should be updated when a
stable
identifier is definitely assigned.

## Background: Transaction-Relay Selection, Announcement & Propagation

At the protocol-level, summarily the transaction relay flow works in the
following way.
On initially broadcasting a transaction, the full-node will issue an
INV(inventory_set)
to all its connected peers. Considering strictly transaction-relay
messages, this inventory
set is composed of either MSG_TX (non-wtxidrelay peers) or MSG_WTX (bip339
wtxidrelay peers),
up to the inventory set limit (if the full-node implements any such
inventory set limit).

For all the transaction identifiers announced in the inventory set, that
are not normally
not already present in the peer inventory or caches at large, the peer will
reply to the
node with a GETDATA(requested_set(MSG_TX)) or
GETDATA(requested_set(MSG_WTX)) message. For
each element in the requested set of transactions, the node can forward an
individual final
TX message to the peer.

The background description is realized using bitcoin core v28.0rc1 - commit
88f0419c1,
and it is assumed to be run similarly by the node and it's connected
transaction-relay peers.

At the implementation-level, bitcoin core presents a number of interfaces
to natively
relay a transaction in the peer-to-peer network, though I'll only give the
background
for 2 of them. Both those interfaces jointly drop transactions identifiers
in the same
buffer, i.e the "forward transaction inventory" (`m_tx_inventory_to_send`).

The 1st) interface examined is the RPC method `sendrawtransaction()`, where
a raw
transaction is shared for broadcast by the node (e.g by the wallet). The
`BroadcastTransaction()`
is called and within this method correspondingly the logic to accept the
single
message with a TX message (`ProcessTransaction()` / `AcceptToMemoryPool()`)
and the
logic to relay the transaction over the peer-to-peer network
(`RelayTransaction()`).
The second part, i.e the transaction relay logic is the one inserting the
transaction
identifier in the forward transaction inventory of each connected
transaction-relay peer.

The 2nd) interface examined is the TX message reception (`NetMsgType::TX`),
where
a raw transaction is received from any connected peer. The transaction
should be processed
by the mempool logic (`ProcessTransaction()`) and if it is accepted it's
going to
be propagated to the remainder of the network (`ProcessValidTx()` /
RelayTransaction()`),
by inserting the transaction identifier in the "forward transaction
inventory".

Come after the transaction selection phase that yield the set of
transactions
to be the object of an INV message to the connected transaction-relay
peers. This
phase is modulated for each connected peer and happens at periodic ticks
(`m_next_inv_send_time`).
During this transaction selection phase, the transactions are topologically
ordered
and fee-rate sorted out from the peer's "forward transaction inventory"
(`m_tx_inventory_to_send`).

This sorted inventory set is then drained up until reaching the
INVENTORY_BROADCAST_MAX
limit (at max: 1000 transactions), and the transaction identifiers are
assembled in
an INV message (either using MSG_TX or MSG_WTX) to be then communicated to
the connected
transaction-relay peers.

After this selection phase, comes the announcement phase on the side of the
node's peer.
At reception of an INV message, the inventory_set received is sorted out,
and if the
inventory element is a transaction (`IsGenTxMsg()`), the transaction
identifier is
processed (`AddTxAnnouncement()`), and if the MAX_PEER_TX_ANNOUNCEMENTS
limit is not
reached, the transaction is queued by the transaction requester
(`TxRequestTracker`).

If the transaction has been uniquely announced by the node, the peer should
issue
a GETDATA download in the future time, driven by the requester logic
(`GetRequestable()`).
If the transactions are announced by the node, faster than the peer can
fetch and
download them, the MAX_PEER_TX_ANNOUNCEMENTS limit provokes transaction to
be dropped
on the floor.

The two limits INVENTORY_BROADCAST_MAX and MAX_PEER_TX_ANNOUNCEMENTS are
the targeted
components by "transaction-throughput overflow attacks" and there will be
further analyzed.

## Problem: Pre-Signed Time-Sensitive Transactions and Bounded
Transaction-Relay Throughput

There are 2 variations of transaction-relay throughput overflow attacks
identified so far,
respectively a "high overflow" attack and a "low overflow" attack. The
explanation is started
by a "high overflow" attack.

### "High-Overflow" Transaction-Relay Throughput Attack

In a "high overflow" attack, the goal of the adversary is to leverage the
fee-rate sort
of the "forward transaction inventory" and the INVENTORY_BROADCAST_MAX to
artificially
stuck down a subset of received transactions in the "forward transaction
inventory".

The attack works in the following fashion against a Lightning routing node:
- there is the Mallet, Alice, Mallory channel topology
- Mallet routes a 0.5 BTC HTLC to Mallory through Alice with an interval
timelock
- Alice and Mallory pre-signs the commitment + HTLC 2nd stage transaction
at 5 sat / vbytes
- at the base-layer level, Alice full-node is connected by 45 inbound peers
controlled by Malicia
- at the base-layer level, Alice is connected with a honest
transaction-relay peer Bob
- Malicia injects 2300 small-size transactions at 10 sat / vbytes for each
of the 45 inbound peers
- at time of the outbound HTLC expiration, Mallory breaks the channel with
Alice, commitment + HTLC 2nd stage transactions are broadcast by Alice
- the constantly injected transaction traffic prevents lightning channel
transactions to propagate on the Alice-Bob link
- after the interval timelock of blocks have been swallowed, the inbound
HTLC is timeout by Mallet, the outbound HTLC is claimed by Mallory

Independently of transaction rebroadcast done by Alice lightning node, as
long as it's done
at the same feerate, it still falls under the feerate threshold in the
"forward transaction
inventory" generated by the throughput overflow traffic.

There is a simplified proof-of-concept of the high overflow of the feerate
sorting
of an alice node's "forward transaction inventory" available here. Tested
on a v27.0
bitcoin core software - commit d822839:

https://github.com/ariard/bitcoin/commit/8fc559a4bcd0a2ef8bb4c50aa540a5c4c61a310a

Note, in this example the feerate parameters are different
('effective-feerate'), i.e
"0.00010416" for the jammed transaction target and "0.00002083" and for the
junk traffic
originating from the feeder connection nodes. Running the test for a few
attempt, yield
around ~2000 transactions, which is consistent with the
INVENTORY_BROADCAST_PER_SECOND limit
of 7 transactions second, or i.e 4200 transactions per average block.

Let's assume safety targeted timelocks are around 40 blocks (which is done
by default by
some lightning network implementations), and the time-sensitive
transactions are pre-signed
at 5 sat / virtual byte. If the individual transaction are of size 100
bytes, the throughput
overflow traffic is pre-signed at 10 sat / virtual byte, the attack
liquidity cost is
estimated to be at 2_100_000 or $2k per block of delay. For a duration of
40 blocks, the
cost is estimated to be at 840_00_000 satoshis or $80_000.

There are 3 observations to be made on this attack liquidity cost.

Firstly, the adversary can partition the victim's full-node mempool from
the rest
of the peer-to-peer network to avoid the throughput overflow transaction
traffic to
be effectively burned as on-chain miners fees. All the overflow transaction
traffic
can be children junk that have a parent in the victim's people (Alice), but
not in
its connected transaction-relay peers (Bob).

Secondly, the adversary can batch the liquidity cost to target a concurrent
number
of lightning channels as lightning routing nodes are operating channels
dissociately
in the lightning network. The throughput overflow limits, if bitcoin core
is run
by default as a full-nodes, can be reached with a single contingent of junk
transactions
originating from a unique UTXO set.

Thirdly, the adversary could recycle the traffic of junk children
transactions
to lower the liquidity cost of the overall attack to few blocks of buffer,
by
periodically spending the parent in the partitioned mempool to a new
confirmed
UTXO, and re-generate a layout of junk children transactions.

### "Low-Overflow" Transaction-Relay Throughput Attack

In a "low overflow" attack, the goal of the adversary is to leverage the
MAX_PEER_TX_ANNOUCEMENTS limit until the inbound transactions received by
the peer from a node overflows this limit and subsequently provokes a drop
of the ulterior inbound transaction traffic.

This attack has been tested under few topological configurations of the
transaction-relay peer-to-peer network, where the MAX_PEER_TX_ANNOUNCEMENTS
inbound limit of a target transaction-relay link is attempted to be
overflowed.

Let's consider the following transaction-relay network topology: Alice
<---> Bob.

Alice and Bob are 2 transaction-relay peers and both of them are running
v28.0rc1.
It is assumed there are supporting wtxidrelay on their connections and that
Alice
opened the connection to Bob (from Alice's node viewpoint Bob is an
outbound peer
or an OUTBOUND_FULL_RELAY).

The name of the game for a "low-overflow" adversary is to open many inbound
connections
to Alice node, and inject a high-number of junk transactions to reach
Alice's "ingress"
limit of MAX_PEER_TX_ANNOUNCEMENTS on each of those inbound connections. As
such trying
to attain Bob's own MAX_PEER_TX_ANNOUNCEMENTS's limit on Alice and Bob link.

Reconsidering the Alice and Bob's topology, let's enrich it with a number of
puppets nodes, and there will be the following topology:
- Mallet <---> Alice
- Mallory <---> Alice
- Malicia <---> Alice

All those 3 puppets inbound nodes are supporting wtxidrelay on theirs
connections
and they are the ones opening connections to Alice (from Alice's node
viewpoint
Mallet, Mallory and Malicia are all inbound peers, from Bob's node
viewpoint they
are completely unrelated peers an ADDR message might not even exist for
them).

Each of this peer can announce and transaction-relay up to 5000 unique and
new transactions to Alice so an "ingress" total of 15k transactions, while
the "egress" on the Alice-Bob link is still only 5000 transactions.

Repeating the trick in the 1st observation about partitioning full-node
mempools,
all the transactions might not connect on Bob's mempool, as such the only
way
for Bob to "discover" it is through announcements on the Alice-Bob link.

This network topology configuration has been tested, while none so far
triggering the MAX_PEER_TX_ANNOUNCEMENT limit on the Alice - Bob connection.

This network topology configuration was initialized with 20 inbound peers
connected to Alice, with each a stock of 4600 transactions to announce to
Alice and the configuration ran for 1 hour. Bob's mempool was accusing
a deficit of ~10k of transactions at the end of the test.

At the 33th minute, the internal buffer of the `TxRequesterTracker` tracking
the number of announced transactions reached the max size of 1252, with an
initial size of 0 (minute 0 ) and a size of 780, at the end of the 60th
minute.

https://github.com/ariard/bitcoin/commit/c958f22e4cb7c193378ad7cd1c05b2c331ad6bd5

This network topology configuration had only one link to be processed by
Bob i.e the Alice-Bob transaction-relay link. More advanced experimental
tests of a "low-overflow throughput" attack could be, e.g (non-exhaustive):
- Bob's node being opened up to `DEFAULT_MAX_PEER_CONNECTIONS` with average
tx traffic
- Bob's node receiving a valid block every 10 min

All those elements are busying the CPUs resources available to the Bob node,
and as such it should diminish processing threads available to process the
"egress" traffic received from Alice, let's say on modern x86_64 chips.

In my reasonable belief, this "low overflow", if it's practical feasibility
can be demonstrated, is indeed more severe than the "high overflow" variant,
as there is no external feerate to meet to thwart the propagation of a
target transaction (e.g a lightning time-sensitive justice transaction).
The liquidity cost is no more linear on the current value of the
MAX_PEER_TX_ANNOUNCEMENT limit and the minimal valid transaction size.

## Solutions

On the pure lightning-side / contracting protocol implementations and node
operators, there are 4 mitigations that can be envisioned. I believe the
mitigation d) can be the more efficient, namely deploying more full-nodes
singly connected to the transaction-relay initiating node to absorb the
overflow of transactions.

a) Random transaction rebroadcast: for "low-overflow", a lightning node
could more aggressively re-sign and rebroadcast time-sensitive transactions,
probabilistically diminishing the odds of the overflow reaching
MAX_PEER_TX_ANNOUNCEMENTS.

b) Aggressive fee-rebroadcasting: for "high-overflow" dynamic
fee-rebroadcasting
can asymmetrically increase the attack cost. On the other hand, this is
increasing
surface to miner harvesting attacks, where a miner could inject junk
children
traffic to trigger a lightning node to fee-bump time-sensitive transactions
[1].

c) Limitation of "Identical Finality" Time-Sensitive Transactions: for
"low-overflow",
a lightning routing hop could limit the number of transactions with the
"identical
finality" (i.e absolute or relative timelock being final at the same chain
tip) to
limit the worst-case flow of time-sensitive transactions that have to
propagate on
the network, at the same chain-defined time period.

d) Over-provisioning transaction-relay throughput with adjacent full-nodes:
both
for "high-overflow" and "low-overflow", the initial transaction-relay node
can
be made no listening for peers connections and block-relay-only. All the
transaction-relay connections can be opened to adjacent "trusted"
full-nodes,
that can swallow more of the overflow traffic. Those adjacent full-nodes can
be regularly connected to the bitcoin network.

Mitigations at the base-layer directly in the transaction-relay stack were
not
seriously considered during the embargo period. In my personal opinion, a
a robust mitigation against transaction-relay throughput attacks could be
more efficient at the base-layer, rather than at the lightning / contracting
protocols levels.

## Timeline
- 2023-06-05: Report of the finding to Bastien Teinturier, Olaoluwa
Osuntokun,
Eugene Siegel, Anthony Towns, Gloria Zhao, Greg Sanders, Matt Corallo, Rusty
Russell, Suhas Daftuar
- 2023-06: Discussions among Lightning folks on real-exercise of the finding
- 2024-07-31: Proposition of a publication date for the finding for December
- 2024-08: Realistic and deployable mitigations discussed among Lightning
folks
- 2024-11-05: Communication of an exact public disclosure date
- 2024-12-03: CVE ID Request shared to the MITRE


## Conclusion

In this report, a new transaction-relay jamming attack against off-chain
protocols
was introduced by exploiting the throughput limits of a full-node
transaction-relay
selection, announcement and propagation algorithms. This attack appears to
be
plausible against lightning channel funds under real-world scenario, while
it
deserves indeed more investigation and experiment.

Two variations of the attacks have been presented, a "high-overflow"
variant,
exploiting the transaction announcement fee-rate sorting algorithm on the
sender-side, and a "low-overflow" variant, exploiting the announcement
processing
limits on the receiver-side. The first variant is presented with a minimal
proof-of-concept, while the second variant is left open for future research.

All mistakes and opinions are my own and please verify any information
reported.

[0] "...should be always evaluated with regards to base layer network
topology,
*tx-relay propagation rules*, mempools behaviors, consistent policy applied
by majority
of nodes and ongoing blockspace demand. All these components are direct
parameters of
LN security. Due to the network being public, a malicious channel
counterparty do have
an incentive to tweak them to steal from you..."

cf. Pinning: The Good, the Bad, the Ugly:
https://gnusha.org/pi/bitcoindev/CALZpt+Ea=GyzEAfJBZzdFvus4_U=x73eA+=J=sN2LONq9_V5dw@mail.gmail.com/

[1]
https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2020-February/002569.txt

-- 
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 visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BEptER%3Dp%2BP7VN3QAb9n%3DdODA9_LnR9xZwWpRsdAwedv%3Dw%40mail.gmail.com.

--0000000000006f1b6a062889811f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>I&#39;m writing a report to disclose a new =
transaction-relay jamming attack<br>affecting bitcoin time-sensitive contra=
cting protocols by exploiting the transaction<br>selection, announcement an=
d propagation mechanisms of base-layer full-nodes.<br><br>Back in 2020, ami=
d numerous technical conversations among bitcoin protocol developers<br>abo=
ut how bip125 replace-by-fee rules could be abused by a lightning channel c=
ounterparty<br>with a competing interest (a.k.a pinning attack, see BIP431&=
#39;s motivation for more), it<br>was thought that few other components of =
the bitcoin tx-relay p2p stack could be also<br>adversarially exploited [0]=
 (In the lack of familiarity with lightning / contracting<br>protocol secur=
ity risks, go to read the old post pointed by footnote).<br><br>Mid-2023, I=
 did privately message a group of long-term bitcoin and lightning<br>develo=
pers detailing those new &quot;transaction-relay throughput attacks&quot; c=
oncerns,<br>especially the different exploitations and the technical feasib=
ility of such attack.<br><br>While this attack was deemed worthy of more in=
vestigations and practical testing, it<br>was relatively put in the backgro=
und due to more severe security issues affecting<br>lightning at the time (=
i.e 2023). Recent conversations this year (i.e 2024) about<br>free relay at=
tacks of full-node bandwidths made me think to reconsider the practical<br>=
cost of transaction-relay throughput attacks, and as such proceeds to a ful=
l disclosure.<br><br>Since my personal awareness in 2020 of this potential =
vector of attack enabling to<br>steal funds from lightning channel funds, I=
&#39;ve not seen exploitations in the wild or<br>corresponding hints that c=
ould reveal such new transaction-relay jamming attack<br>being practically =
used.<br><br>In this report, 2 variations of those new &quot;transaction-re=
lay throughput attacks&quot;<br>are presented, i.e respectively the &quot;h=
igh overflow&quot; and the &quot;low overflow&quot; variant.<br>There is a =
proof-of-concept available for the &quot;high overflow&quot; variation test=
ed on<br>bitcoin core v27.0. The &quot;high overflow&quot; variation has be=
en tested under few topological<br>configurations, though no under real-wor=
ld workload. Coming with a proof-of-concept<br>to demonstrate the feasibili=
ty of the 2nd variation stays an open subject of investigation.<br>(see cor=
responding subsection for more).<br><br>After conversation with few lightni=
ng maintainers, it arises as a main conclusion<br>that currently deployed r=
andom rebroadcast of time-sensitive transactions was probably<br>one of the=
 most effective mitigation that could be solely deployed by lightning<br>im=
plementation themselves. In this report, 2 variations of those new &quot;tr=
ansaction-relay<br>throughput attacks&quot; are presented, i.e respectively=
 the &quot;high overflow&quot; and &quot;low overflow&quot;<br>variants.<br=
><br>At the time of writing, the &quot;high overflow&quot; attack cost is e=
valuated to be around<br>$80k to target real-world lightning channels with =
safety timelocks in the the order<br>of four dozen of blocks.<br><br>In my =
reasonable opinion, I believe this new transaction-relay jamming attack can=
<br>be as much severe than already known state of the art non-mitigated att=
acks against<br>lightning channels while minding the junk transaction traff=
ic cost. However more<br>investigations of this transaction-relay throughpu=
t attack vector can be very valuable.<br><br>This new off-chain protocol at=
tack vector is currently tracked by the CVE<br>Request 1780258 shared to th=
e MITRE, under a single identifier for a &quot;multiple<br>software, same p=
rotocol / attack vector&quot;. Report should be updated when a stable<br>id=
entifier is definitely assigned.<br><br>## Background: Transaction-Relay Se=
lection, Announcement &amp; Propagation<br><br>At the protocol-level, summa=
rily the transaction relay flow works in the following way.<br>On initially=
 broadcasting a transaction, the full-node will issue an INV(inventory_set)=
<br>to all its connected peers. Considering strictly transaction-relay mess=
ages, this inventory<br>set is composed of either MSG_TX (non-wtxidrelay pe=
ers) or MSG_WTX (bip339 wtxidrelay peers),<br>up to the inventory set limit=
 (if the full-node implements any such inventory set limit).<br><br>For all=
 the transaction identifiers announced in the inventory set, that are not n=
ormally<br>not already present in the peer inventory or caches at large, th=
e peer will reply to the<br>node with a GETDATA(requested_set(MSG_TX)) or G=
ETDATA(requested_set(MSG_WTX)) message. For<br>each element in the requeste=
d set of transactions, the node can forward an individual final<br>TX messa=
ge to the peer.<br><br>The background description is realized using bitcoin=
 core v28.0rc1 - commit 88f0419c1,<br>and it is assumed to be run similarly=
 by the node and it&#39;s connected transaction-relay peers.<br><br>At the =
implementation-level, bitcoin core presents a number of interfaces to nativ=
ely<br>relay a transaction in the peer-to-peer network, though I&#39;ll onl=
y give the background<br>for 2 of them. Both those interfaces jointly drop =
transactions identifiers in the same<br>buffer, i.e the &quot;forward trans=
action inventory&quot; (`m_tx_inventory_to_send`).<br><br>The 1st) interfac=
e examined is the RPC method `sendrawtransaction()`, where a raw<br>transac=
tion is shared for broadcast by the node (e.g by the wallet). The `Broadcas=
tTransaction()`<br>is called and within this method correspondingly the log=
ic to accept the single<br>message with a TX message (`ProcessTransaction()=
` / `AcceptToMemoryPool()`) and the<br>logic to relay the transaction over =
the peer-to-peer network (`RelayTransaction()`).<br>The second part, i.e th=
e transaction relay logic is the one inserting the transaction<br>identifie=
r in the forward transaction inventory of each connected transaction-relay =
peer.<br><br>The 2nd) interface examined is the TX message reception (`NetM=
sgType::TX`), where<br>a raw transaction is received from any connected pee=
r. The transaction should be processed<br>by the mempool logic (`ProcessTra=
nsaction()`) and if it is accepted it&#39;s going to<br>be propagated to th=
e remainder of the network (`ProcessValidTx()` / RelayTransaction()`),<br>b=
y inserting the transaction identifier in the &quot;forward transaction inv=
entory&quot;.<br><br>Come after the transaction selection phase that yield =
the set of transactions<br>to be the object of an INV message to the connec=
ted transaction-relay peers. This<br>phase is modulated for each connected =
peer and happens at periodic ticks (`m_next_inv_send_time`).<br>During this=
 transaction selection phase, the transactions are topologically ordered<br=
>and fee-rate sorted out from the peer&#39;s &quot;forward transaction inve=
ntory&quot; (`m_tx_inventory_to_send`).<br><br>This sorted inventory set is=
 then drained up until reaching the INVENTORY_BROADCAST_MAX<br>limit (at ma=
x: 1000 transactions), and the transaction identifiers are assembled in<br>=
an INV message (either using MSG_TX or MSG_WTX) to be then communicated to =
the connected<br>transaction-relay peers.<br><br>After this selection phase=
, comes the announcement phase on the side of the node&#39;s peer.<br>At re=
ception of an INV message, the inventory_set received is sorted out, and if=
 the<br>inventory element is a transaction (`IsGenTxMsg()`), the transactio=
n identifier is<br>processed (`AddTxAnnouncement()`), and if the MAX_PEER_T=
X_ANNOUNCEMENTS limit is not<br>reached, the transaction is queued by the t=
ransaction requester (`TxRequestTracker`).<br><br>If the transaction has be=
en uniquely announced by the node, the peer should issue<br>a GETDATA downl=
oad in the future time, driven by the requester logic (`GetRequestable()`).=
<br>If the transactions are announced by the node, faster than the peer can=
 fetch and<br>download them, the MAX_PEER_TX_ANNOUNCEMENTS limit provokes t=
ransaction to be dropped<br>on the floor.<br><br>The two limits INVENTORY_B=
ROADCAST_MAX and MAX_PEER_TX_ANNOUNCEMENTS are the targeted<br>components b=
y &quot;transaction-throughput overflow attacks&quot; and there will be fur=
ther analyzed.<br><br>## Problem: Pre-Signed Time-Sensitive Transactions an=
d Bounded Transaction-Relay Throughput<br><br>There are 2 variations of tra=
nsaction-relay throughput overflow attacks identified so far,<br>respective=
ly a &quot;high overflow&quot; attack and a &quot;low overflow&quot; attack=
. The explanation is started<br>by a &quot;high overflow&quot; attack.<br><=
br>### &quot;High-Overflow&quot; Transaction-Relay Throughput Attack<br><br=
>In a &quot;high overflow&quot; attack, the goal of the adversary is to lev=
erage the fee-rate sort<br>of the &quot;forward transaction inventory&quot;=
 and the INVENTORY_BROADCAST_MAX to artificially<br>stuck down a subset of =
received transactions in the &quot;forward transaction inventory&quot;.<br>=
<br>The attack works in the following fashion against a Lightning routing n=
ode:<br>- there is the Mallet, Alice, Mallory channel topology<br>- Mallet =
routes a 0.5 BTC HTLC to Mallory through Alice with an interval timelock<br=
>- Alice and Mallory pre-signs the commitment + HTLC 2nd stage transaction =
at 5 sat / vbytes<br>- at the base-layer level, Alice full-node is connecte=
d by 45 inbound peers controlled by Malicia<br>- at the base-layer level, A=
lice is connected with a honest transaction-relay peer Bob<br>- Malicia inj=
ects 2300 small-size transactions at 10 sat / vbytes for each of the 45 inb=
ound peers<br>- at time of the outbound HTLC expiration, Mallory breaks the=
 channel with Alice, commitment + HTLC 2nd stage transactions are broadcast=
 by Alice<br>- the constantly injected transaction traffic prevents lightni=
ng channel transactions to propagate on the Alice-Bob link<br>- after the i=
nterval timelock of blocks have been swallowed, the inbound HTLC is timeout=
 by Mallet, the outbound HTLC is claimed by Mallory<br><br>Independently of=
 transaction rebroadcast done by Alice lightning node, as long as it&#39;s =
done<br>at the same feerate, it still falls under the feerate threshold in =
the &quot;forward transaction<br>inventory&quot; generated by the throughpu=
t overflow traffic.<br><br>There is a simplified proof-of-concept of the hi=
gh overflow of the feerate sorting<br>of an alice node&#39;s &quot;forward =
transaction inventory&quot; available here. Tested on a v27.0<br>bitcoin co=
re software - commit d822839:<br><br><a href=3D"https://github.com/ariard/b=
itcoin/commit/8fc559a4bcd0a2ef8bb4c50aa540a5c4c61a310a">https://github.com/=
ariard/bitcoin/commit/8fc559a4bcd0a2ef8bb4c50aa540a5c4c61a310a</a><br><br>N=
ote, in this example the feerate parameters are different (&#39;effective-f=
eerate&#39;), i.e<br>&quot;0.00010416&quot; for the jammed transaction targ=
et and &quot;0.00002083&quot; and for the junk traffic<br>originating from =
the feeder connection nodes. Running the test for a few attempt, yield<br>a=
round ~2000 transactions, which is consistent with the INVENTORY_BROADCAST_=
PER_SECOND limit<br>of 7 transactions second, or i.e 4200 transactions per =
average block.<br><br>Let&#39;s assume safety targeted timelocks are around=
 40 blocks (which is done by default by<br>some lightning network implement=
ations), and the time-sensitive transactions are pre-signed<br>at 5 sat / v=
irtual byte. If the individual transaction are of size 100 bytes, the throu=
ghput<br>overflow traffic is pre-signed at 10 sat / virtual byte, the attac=
k liquidity cost is<br>estimated to be at 2_100_000 or $2k per block of del=
ay. For a duration of 40 blocks, the<br>cost is estimated to be at 840_00_0=
00 satoshis or $80_000.<br><br>There are 3 observations to be made on this =
attack liquidity cost.<br><br>Firstly, the adversary can partition the vict=
im&#39;s full-node mempool from the rest<br>of the peer-to-peer network to =
avoid the throughput overflow transaction traffic to<br>be effectively burn=
ed as on-chain miners fees. All the overflow transaction traffic<br>can be =
children junk that have a parent in the victim&#39;s people (Alice), but no=
t in<br>its connected transaction-relay peers (Bob).<br><br>Secondly, the a=
dversary can batch the liquidity cost to target a concurrent number<br>of l=
ightning channels as lightning routing nodes are operating channels dissoci=
ately<br>in the lightning network. The throughput overflow limits, if bitco=
in core is run<br>by default as a full-nodes, can be reached with a single =
contingent of junk transactions<br>originating from a unique UTXO set.<br><=
br>Thirdly, the adversary could recycle the traffic of junk children transa=
ctions<br>to lower the liquidity cost of the overall attack to few blocks o=
f buffer, by <br>periodically spending the parent in the partitioned mempoo=
l to a new confirmed<br>UTXO, and re-generate a layout of junk children tra=
nsactions.<br><br>### &quot;Low-Overflow&quot; Transaction-Relay Throughput=
 Attack<br><br>In a &quot;low overflow&quot; attack, the goal of the advers=
ary is to leverage the<br>MAX_PEER_TX_ANNOUCEMENTS limit until the inbound =
transactions received by<br>the peer from a node overflows this limit and s=
ubsequently provokes a drop<br>of the ulterior inbound transaction traffic.=
<br><br>This attack has been tested under few topological configurations of=
 the<br>transaction-relay peer-to-peer network, where the MAX_PEER_TX_ANNOU=
NCEMENTS<br>inbound limit of a target transaction-relay link is attempted t=
o be overflowed.<br><br>Let&#39;s consider the following transaction-relay =
network topology: Alice &lt;---&gt; Bob.<br><br>Alice and Bob are 2 transac=
tion-relay peers and both of them are running v28.0rc1.<br>It is assumed th=
ere are supporting wtxidrelay on their connections and that Alice<br>opened=
 the connection to Bob (from Alice&#39;s node viewpoint Bob is an outbound =
peer<br>or an OUTBOUND_FULL_RELAY).<br><br>The name of the game for a &quot=
;low-overflow&quot; adversary is to open many inbound connections<br>to Ali=
ce node, and inject a high-number of junk transactions to reach Alice&#39;s=
 &quot;ingress&quot;<br>limit of MAX_PEER_TX_ANNOUNCEMENTS on each of those=
 inbound connections. As such trying<br>to attain Bob&#39;s own MAX_PEER_TX=
_ANNOUNCEMENTS&#39;s limit on Alice and Bob link.<br><br>Reconsidering the =
Alice and Bob&#39;s topology, let&#39;s enrich it with a number of<br>puppe=
ts nodes, and there will be the following topology:<br>- Mallet &lt;---&gt;=
 Alice<br>- Mallory &lt;---&gt; Alice<br>- Malicia &lt;---&gt; Alice<br><br=
>All those 3 puppets inbound nodes are supporting wtxidrelay on theirs conn=
ections<br>and they are the ones opening connections to Alice (from Alice&#=
39;s node viewpoint<br>Mallet, Mallory and Malicia are all inbound peers, f=
rom Bob&#39;s node viewpoint they<br>are completely unrelated peers an ADDR=
 message might not even exist for them).<br><br>Each of this peer can annou=
nce and transaction-relay up to 5000 unique and<br>new transactions to Alic=
e so an &quot;ingress&quot; total of 15k transactions, while<br>the &quot;e=
gress&quot; on the Alice-Bob link is still only 5000 transactions.<br><br>R=
epeating the trick in the 1st observation about partitioning full-node memp=
ools,<br>all the transactions might not connect on Bob&#39;s mempool, as su=
ch the only way<br>for Bob to &quot;discover&quot; it is through announceme=
nts on the Alice-Bob link.<br><br>This network topology configuration has b=
een tested, while none so far<br>triggering the MAX_PEER_TX_ANNOUNCEMENT li=
mit on the Alice - Bob connection.<br><br>This network topology configurati=
on was initialized with 20 inbound peers<br>connected to Alice, with each a=
 stock of 4600 transactions to announce to<br>Alice and the configuration r=
an for 1 hour. Bob&#39;s mempool was accusing<br>a deficit of ~10k of trans=
actions at the end of the test.<br><br>At the 33th minute, the internal buf=
fer of the `TxRequesterTracker` tracking<br>the number of announced transac=
tions reached the max size of 1252, with an<br>initial size of 0 (minute 0 =
) and a size of 780, at the end of the 60th minute.<br><br><a href=3D"https=
://github.com/ariard/bitcoin/commit/c958f22e4cb7c193378ad7cd1c05b2c331ad6bd=
5">https://github.com/ariard/bitcoin/commit/c958f22e4cb7c193378ad7cd1c05b2c=
331ad6bd5</a><br><br>This network topology configuration had only one link =
to be processed by<br>Bob i.e the Alice-Bob transaction-relay link. More ad=
vanced experimental<br>tests of a &quot;low-overflow throughput&quot; attac=
k could be, e.g (non-exhaustive):<br>- Bob&#39;s node being opened up to `D=
EFAULT_MAX_PEER_CONNECTIONS` with average tx traffic<br>- Bob&#39;s node re=
ceiving a valid block every 10 min<br><br>All those elements are busying th=
e CPUs resources available to the Bob node,<br>and as such it should dimini=
sh processing threads available to process the<br>&quot;egress&quot; traffi=
c received from Alice, let&#39;s say on modern x86_64 chips.<br><br>In my r=
easonable belief, this &quot;low overflow&quot;, if it&#39;s practical feas=
ibility<br>can be demonstrated, is indeed more severe than the &quot;high o=
verflow&quot; variant,<br>as there is no external feerate to meet to thwart=
 the propagation of a<br>target transaction (e.g a lightning time-sensitive=
 justice transaction). <br>The liquidity cost is no more linear on the curr=
ent value of the<br>MAX_PEER_TX_ANNOUNCEMENT limit and the minimal valid tr=
ansaction size.<br><br>## Solutions<br><br>On the pure lightning-side / con=
tracting protocol implementations and node<br>operators, there are 4 mitiga=
tions that can be envisioned. I believe the<br>mitigation d) can be the mor=
e efficient, namely deploying more full-nodes<br>singly connected to the tr=
ansaction-relay initiating node to absorb the<br>overflow of transactions.<=
br><br>a) Random transaction rebroadcast: for &quot;low-overflow&quot;, a l=
ightning node<br>could more aggressively re-sign and rebroadcast time-sensi=
tive transactions,<br>probabilistically diminishing the odds of the overflo=
w reaching<br>MAX_PEER_TX_ANNOUNCEMENTS.<br><br>b) Aggressive fee-rebroadca=
sting: for &quot;high-overflow&quot; dynamic fee-rebroadcasting<br>can asym=
metrically increase the attack cost. On the other hand, this is increasing<=
br>surface to miner harvesting attacks, where a miner could inject junk chi=
ldren<br>traffic to trigger a lightning node to fee-bump time-sensitive tra=
nsactions [1].<br><br>c) Limitation of &quot;Identical Finality&quot; Time-=
Sensitive Transactions: for &quot;low-overflow&quot;,<br>a lightning routin=
g hop could limit the number of transactions with the &quot;identical<br>fi=
nality&quot; (i.e absolute or relative timelock being final at the same cha=
in tip) to<br>limit the worst-case flow of time-sensitive transactions that=
 have to propagate on<br>the network, at the same chain-defined time period=
.<br><br>d) Over-provisioning transaction-relay throughput with adjacent fu=
ll-nodes: both<br>for &quot;high-overflow&quot; and &quot;low-overflow&quot=
;, the initial transaction-relay node can<br>be made no listening for peers=
 connections and block-relay-only. All the<br>transaction-relay connections=
 can be opened to adjacent &quot;trusted&quot; full-nodes,<br>that can swal=
low more of the overflow traffic. Those adjacent full-nodes can<br>be regul=
arly connected to the bitcoin network.<br><br>Mitigations at the base-layer=
 directly in the transaction-relay stack were not<br>seriously considered d=
uring the embargo period. In my personal opinion, a<br>a robust mitigation =
against transaction-relay throughput attacks could be<br>more efficient at =
the base-layer, rather than at the lightning / contracting<br>protocols lev=
els.<br><br>## Timeline<br>- 2023-06-05: Report of the finding to Bastien T=
einturier, Olaoluwa Osuntokun,<br>Eugene Siegel, Anthony Towns, Gloria Zhao=
, Greg Sanders, Matt Corallo, Rusty<br>Russell, Suhas Daftuar<br>- 2023-06:=
 Discussions among Lightning folks on real-exercise of the finding<br>- 202=
4-07-31: Proposition of a publication date for the finding for December<br>=
- 2024-08: Realistic and deployable mitigations discussed among Lightning f=
olks<br>- 2024-11-05: Communication of an exact public disclosure date<br>-=
 2024-12-03: CVE ID Request shared to the MITRE<br><br><br>## Conclusion<br=
><br>In this report, a new transaction-relay jamming attack against off-cha=
in protocols<br>was introduced by exploiting the throughput limits of a ful=
l-node transaction-relay<br>selection, announcement and propagation algorit=
hms. This attack appears to be<br>plausible against lightning channel funds=
 under real-world scenario, while it<br>deserves indeed more investigation=
=C2=A0and experiment.<br><br>Two variations of the attacks have been presen=
ted, a &quot;high-overflow&quot; variant,<br>exploiting the transaction ann=
ouncement fee-rate sorting algorithm on the<br>sender-side, and a &quot;low=
-overflow&quot; variant, exploiting the announcement processing<br>limits o=
n the receiver-side. The first variant is presented with a minimal<br>proof=
-of-concept, while the second variant is left open for future research.<br>=
<br>All mistakes and opinions are my own and please verify any information =
reported.<br><br>[0] &quot;...should be always evaluated with regards to ba=
se layer network topology, <br>*tx-relay propagation rules*, mempools behav=
iors, consistent policy applied by majority<br>of nodes and ongoing blocksp=
ace demand. All these components are direct parameters of<br>LN security. D=
ue to the network being public, a malicious channel counterparty do have<br=
>an incentive to tweak them to steal from you...&quot; <br><br>cf. Pinning:=
 The Good, the Bad, the Ugly: <a href=3D"https://gnusha.org/pi/bitcoindev/C=
ALZpt+Ea=3DGyzEAfJBZzdFvus4_U=3Dx73eA+=3DJ=3DsN2LONq9_V5dw@mail.gmail.com/"=
>https://gnusha.org/pi/bitcoindev/CALZpt+Ea=3DGyzEAfJBZzdFvus4_U=3Dx73eA+=
=3DJ=3DsN2LONq9_V5dw@mail.gmail.com/</a><br><br>[1] <a href=3D"https://diyh=
pl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-de=
v/2020-February/002569.txt">https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-de=
v/linuxfoundation-pipermail/lightning-dev/2020-February/002569.txt</a><br><=
/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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CALZpt%2BEptER%3Dp%2BP7VN3QAb9n%3DdODA9_LnR9xZwWpRsdAwedv%3Dw%40=
mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/d/msgid/bitcoindev/CALZpt%2BEptER%3Dp%2BP7VN3QAb9n%3DdODA9_LnR9xZwWpR=
sdAwedv%3Dw%40mail.gmail.com</a>.<br />

--0000000000006f1b6a062889811f--