* [bitcoindev] Update on Transaction Relay V2
@ 2025-02-19 3:36 Antoine Riard
0 siblings, 0 replies; only message in thread
From: Antoine Riard @ 2025-02-19 3:36 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5108 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 5860 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2025-02-23 20:07 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-02-19 3:36 [bitcoindev] Update on Transaction Relay V2 Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox