From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 23 Feb 2025 12:07:09 -0800 Received: from mail-yw1-f192.google.com ([209.85.128.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tmIFo-0004gz-Jl for bitcoindev@gnusha.org; Sun, 23 Feb 2025 12:07:09 -0800 Received: by mail-yw1-f192.google.com with SMTP id 00721157ae682-6f2c7008c05sf51573947b3.0 for ; Sun, 23 Feb 2025 12:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1740341223; x=1740946023; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=BXmsfYXPn/zK3042zlmTJndZhJM0vFPtkyGRX2fX5/s=; b=QOLL/2UFhOI7V8InhfXG3lCh7BW1ww4qxji+gyaTKUotHjtI2SreksWdXATxrddiJM Y+zFVDIcGyHhJoY/wae7DwrzseqpGTrTKpFcsbcH1QZrQeAueAtBPSkvYm+FCN4jPOma DF/u9uhml28eF01nxrh408xi2OcpLSHftjytLfuyHJ5zysK4/z8RzXBEEssgb/rb/816 1/y28ZiwGxjnf4xBlryD1QELDA6t2GofK71utQ4da8Mirh5wJtOVfg7IhEa+2MSp046a ShLY4qVl/b+Dntgh7Hywqg2SIMXxFSnfaKwtDIqtN8H+7VE2wpBDsdvowoyJIE+Uw9aD AHtg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740341223; x=1740946023; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=BXmsfYXPn/zK3042zlmTJndZhJM0vFPtkyGRX2fX5/s=; b=MTD+9NQQ2s/F1LIXixdBzQXf7mGR/re8jdBbfdaxyuB8CsJ0eLgz8iVmMVZWALyms3 ukEBIC12ZCHGwFqJ3izEiO7TICkt1dGgNyc9K6eN0ENk7fSdaNzY/Zkvx3qShcUX8Ahh hCPnG2Gm6ozDBrgDv53bc3lkrH5TiOF9riouWbijPnO2D8hFHdHcmbicudtfIye/NSAZ MV39WI2F7t24njjZ1n9VM934k2JFlVTlObB31jUuCrnT7Tu2OKlo5KXJbE6RHnLIGeeB iDgHymiz1Tn0Y9lO2WbEvyAcsnclGVI8gLLUJUNmGfpNb2pJJjglKPNCqivep24INEUD j1Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740341223; x=1740946023; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=BXmsfYXPn/zK3042zlmTJndZhJM0vFPtkyGRX2fX5/s=; b=FYVlt4q512E8zla8Dxp7kgdhBYEs640vmOpnlymyWatyIEyXqskjhRtUii16TaQj5a dNxrunRD2UWwBbUcNcaVecPpn2+IFjw9x97iheXlKWiBexFWh26pGggYVlmGl9F5JG7X 0aMX0A+on9cav+t/dQEQa8faew+7ovyLyafrPD3sgwxNgKoCWylb8n43gfAE1jOvTN63 fhdEaPCy0ywcxLisjOjCo2KFuU5NbB+z1OqsBwNUHb83VDWqLoNzz0A1znQuRV9TqX+2 JN33j10uWio07DfqF2EspEs7dw4AO5niHf5mCcTmO6wrnNUfw/Esif+k/O+fiuz7Ub7r Q3Pg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXV+tgq9zvLAm2wx0OkJ7mEcH6nOQ4TD5OfMX+JZlgpV2kqnuYvr9bPYaElSQtqY8OahjOoEZ1UhfVp@gnusha.org X-Gm-Message-State: AOJu0YyFSHcLCM58I344MVDesm7eum2iczmILgm16gRm4PH1bK03O8PU pGBzDIxHANvUEQAZWrehS8j+8NK80i1nl2k812uRLMPrBycyhPy1 X-Google-Smtp-Source: AGHT+IHfwLbKgU3Nr/38en75nzXIc9KJEqMRD7Zoz21bxKItu6bEleS0ZVpe43XUso0TbV/We+OOCg== X-Received: by 2002:a05:6902:248f:b0:e5d:bf2a:ba02 with SMTP id 3f1490d57ef6-e5e246a4fcemr9059222276.49.1740341222696; Sun, 23 Feb 2025 12:07:02 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVELz1+3z4/3LL+ko6pyp5ZlEcizDS78nGo0TETdCNkT5Q== Received: by 2002:a5b:749:0:b0:e5b:3447:bb06 with SMTP id 3f1490d57ef6-e5e1aaa9df6ls889378276.1.-pod-prod-01-us; Sun, 23 Feb 2025 12:06:59 -0800 (PST) X-Received: by 2002:a05:690c:6201:b0:6f9:72a9:f7cd with SMTP id 00721157ae682-6fbcc23a5cdmr85781927b3.9.1740341219719; Sun, 23 Feb 2025 12:06:59 -0800 (PST) Received: by 2002:a81:be1a:0:b0:6f9:77a0:782b with SMTP id 00721157ae682-6fb44a6cc87ms7b3; Tue, 18 Feb 2025 19:36:52 -0800 (PST) X-Received: by 2002:a05:690c:f89:b0:6fb:56b3:307c with SMTP id 00721157ae682-6fb5829cdc4mr132313707b3.14.1739936209613; Tue, 18 Feb 2025 19:36:49 -0800 (PST) Date: Tue, 18 Feb 2025 19:36:49 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] Update on Transaction Relay V2 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_221732_156492301.1739936209062" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_221732_156492301.1739936209062 Content-Type: multipart/alternative; boundary="----=_Part_221733_1007132400.1739936209062" ------=_Part_221733_1007132400.1739936209062 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_221733_1007132400.1739936209062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi devs,

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

## Problems

As a reminder, the Bitcoin tran= saction-relay protocol in its simple flow (i.e
no package and no erlay= ) for inter-node single transaction communication works
in the followi= ng 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 re= plies with GETDATA(MSG_TX, TXID)
- node A forwards the new transaction= with a TX message

As far as I know, the transaction-relay proto= col as work in the following
way since the very first releases of the = original bitcoin software. There is
indeed a myriad of other subtletie= s 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 pra= ctical problems.

## 1. Transaction-Relay as Denial-of-Service Ve= ctor

There could be scenarios where puppets peers are deliberate= ly sending junk
transactions traffic that is burdening a target node C= PU time [3] [4]. In my
understanding, this is not necessarily one of t= he 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. Indee= d, 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 in= formation on the transaction-relay
network topology (e.g observing a c= onflict or not), even discover which node
is the initial broadcast ent= ry point of a target transaction.

## 3. Transaction-Relay Throug= hput 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 t= o the
best of my knowledge is the only one that has been practically d= emonstrated,
an adversary exploits the fee-rate sorting of the INV mes= sage selection algorithm
to jam a pre-signed time-sensitive transactio= n until timelock expiration. This
attack works in jamming transaction-= relay link between 2 _honest_ full-node peers,
where the adversary jus= t have connections to one of the peer.

## Proposed Solution: Str= ict 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
l= east as a initial building block for more complete solutions.

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

Alleviating thi= s issue, one of the draft BIP proposes to introduce a new
versioning o= f the transaction-relay protocol.

Excerpt:

```
<= br />Peers supporting the v2 transaction relay protocol signal support by a= dverstising
the 13th bit service flag in the addr p2p messages (`ADDR`= and `ADDRV2`).

```

This is not a perfect solution, a= s that means non-upgraded peers can still
use the open connection slot= s for this to provoke one of the troubleshoot
problems exposed above. = There is an implementation of this idea that has
been opened on bitcoi= n 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 intr= oducing
a future v2 transaction-relay protocol.

Cheers,
Antoine
OTS hash: 5d0bbfd70054e5075a27058f53046108658b9b032ec4fa81ff= 6741a45b8a051d

[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.gma= il.com/
[3] https://github.com/bitcoin/bitcoin/issues/31033
[4] h= ttps://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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/e98ec3a3-b88b-4616-8f46-58353703d206n%40googlegroups.com.
------=_Part_221733_1007132400.1739936209062-- ------=_Part_221732_156492301.1739936209062--