Hi devs,

This email is a digest of the ongoing work to improve the transaction-relay
protocol among bitcoin full-nodes. The proposed improvements are motivated
for diverse reasons detailed subsequently. Currently, there has been 2 draft
BIPs proposed [0] [1]. A modular overhaul of the transaction-relay protocol
was already discussed few years ago [2].

## Problems

As a reminder, the Bitcoin transaction-relay protocol in its simple flow 
(i.e
no package and no erlay) for inter-node single transaction communication 
works
in the following rough way:
- a wallet do an initial broadcast of a new tx to a node A
- node A do an INV(MSG_TX, TXID) message to node B
- node B replies with GETDATA(MSG_TX, TXID)
- node A forwards the new transaction with a TX message

As far as I know, the transaction-relay protocol as work in the following
way since the very first releases of the original bitcoin software. There is
indeed a myriad of other subtleties that have been added in the time, for 
good
reasons, here go to see a full-node codebase.

This approach comes up with a number of practical problems.

## 1. Transaction-Relay as Denial-of-Service Vector

There could be scenarios where puppets peers are deliberately sending junk
transactions traffic that is burdening a target node CPU time [3] [4]. In my
understanding, this is not necessarily one of the most concerning DoS risk
affecting Bitcoin full-nodes partaking in in the transaction-relay network,
however this can be still concerning.

## 2. Transaction-Propagation Deanonymization Vector

Some gap in the current transaction-relay protocol allows mass-connectors
to broadcast transactions without first sending an INV message. Indeed, 
current
bitcoin core software accepts a raw TX message, even if has not been paired 
by
an INV or asked for by a GETDATA. Exploiting this behavior, mass-connectors
can bypass tx-relay timers to gather more information on the 
transaction-relay
network topology (e.g observing a conflict or not), even discover which node
is the initial broadcast entry point of a target transaction.

## 3. Transaction-Relay Throughput Overflow Attacks on Contracting Protocols

More recently, it has been exposed that bitcoin contracting protocols (i.e
things like Lightning heavily relying on timelocks for its security models)
can be practically vulnerable to "transaction-relay througput overflow 
attacks"
(tracked under CVE-2024-55563). In the "high-overflow" variant, which to the
best of my knowledge is the only one that has been practically demonstrated,
an adversary exploits the fee-rate sorting of the INV message selection 
algorithm
to jam a pre-signed time-sensitive transaction until timelock expiration. 
This
attack works in jamming transaction-relay link between 2 _honest_ full-node 
peers,
where the adversary just have connections to one of the peer.

## Proposed Solution: Strict Validation of Transaction Message Dance

In my understanding, all the problems are intersecting on the lack of strict
validation of the transaction messages dance (INV <- ; GETDATA -> ; TX), at
least as a initial building block for more complete solutions.

There is a known pratical downside of asserting strict validation of the
transaction message dance as one of the property wished to solve the layout
problems, namely deployment would break wallets and clients relying on "just
do a raw TX" relay of transaction (and from browsing some wallet libraries,
actually some are doing it).

Alleviating this issue, one of the draft BIP proposes to introduce a new
versioning of the transaction-relay protocol.

Excerpt:

```

Peers supporting the v2 transaction relay protocol signal support by 
adverstising
the 13th bit service flag in the addr p2p messages (`ADDR` and `ADDRV2`).

```

This is not a perfect solution, as that means non-upgraded peers can still
use the open connection slots for this to provoke one of the troubleshoot
problems exposed above. There is an implementation of this idea that has
been opened on bitcoin core, though from the discussions no idea has arised
on how to keep supporting non-upgraded clients in the less disruptive 
fashion.

Eager to gather feedback if alternative solutions can exist instead of 
introducing
a future v2 transaction-relay protocol.

Cheers,
Antoine
OTS hash: 5d0bbfd70054e5075a27058f53046108658b9b032ec4fa81ff6741a45b8a051d

[0] https://github.com/bitcoin/bips/pull/1663
[1] https://github.com/bitcoin/bips/pull/1664
[2] 
https://gnusha.org/pi/bitcoindev/CALZpt+E6UqB5cew145PO2qiEMsELJ-TuGyE5PBL04T1tESiOiQ@mail.gmail.com/
[3] https://github.com/bitcoin/bitcoin/issues/31033
[4] https://github.com/bitcoin/bitcoin/pull/30572
[5] https://groups.google.com/g/bitcoindev/c/GuS36ldye7s

-- 
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/e98ec3a3-b88b-4616-8f46-58353703d206n%40googlegroups.com.