path: root/cc/b53e4b831ab79c06a2bcaa4004ed1712792d52

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 <bitcoindev+bncBC3PT7FYWAMRBZH75W6QMGQERW6UX7Q@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <e98ec3a3-b88b-4616-8f46-58353703d206n@googlegroups.com>
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: <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_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,<br /><br />This email is a digest of the ongoing work to improve t=
he transaction-relay<br />protocol among bitcoin full-nodes. The proposed i=
mprovements are motivated<br />for diverse reasons detailed subsequently. C=
urrently, there has been 2 draft<br />BIPs proposed [0] [1]. A modular over=
haul of the transaction-relay protocol<br />was already discussed few years=
 ago [2].<br /><br />## Problems<br /><br />As a reminder, the Bitcoin tran=
saction-relay protocol in its simple flow (i.e<br />no package and no erlay=
) for inter-node single transaction communication works<br />in the followi=
ng rough way:<br />- a wallet do an initial broadcast of a new tx to a node=
 A<br />- node A do an INV(MSG_TX, TXID) message to node B<br />- node B re=
plies with GETDATA(MSG_TX, TXID)<br />- node A forwards the new transaction=
 with a TX message<br /><br />As far as I know, the transaction-relay proto=
col as work in the following<br />way since the very first releases of the =
original bitcoin software. There is<br />indeed a myriad of other subtletie=
s that have been added in the time, for good<br />reasons, here go to see a=
 full-node codebase.<br /><br />This approach comes up with a number of pra=
ctical problems.<br /><br />## 1. Transaction-Relay as Denial-of-Service Ve=
ctor<br /><br />There could be scenarios where puppets peers are deliberate=
ly sending junk<br />transactions traffic that is burdening a target node C=
PU time [3] [4]. In my<br />understanding, this is not necessarily one of t=
he most concerning DoS risk<br />affecting Bitcoin full-nodes partaking in =
in the transaction-relay network,<br />however this can be still concerning=
.<br /><br />## 2. Transaction-Propagation Deanonymization Vector<br /><br =
/>Some gap in the current transaction-relay protocol allows mass-connectors=
<br />to broadcast transactions without first sending an INV message. Indee=
d, current<br />bitcoin core software accepts a raw TX message, even if has=
 not been paired by<br />an INV or asked for by a GETDATA. Exploiting this =
behavior, mass-connectors<br />can bypass tx-relay timers to gather more in=
formation on the transaction-relay<br />network topology (e.g observing a c=
onflict or not), even discover which node<br />is the initial broadcast ent=
ry point of a target transaction.<br /><br />## 3. Transaction-Relay Throug=
hput Overflow Attacks on Contracting Protocols<br /><br />More recently, it=
 has been exposed that bitcoin contracting protocols (i.e<br />things like =
Lightning heavily relying on timelocks for its security models)<br />can be=
 practically vulnerable to "transaction-relay througput overflow attacks"<b=
r />(tracked under CVE-2024-55563). In the "high-overflow" variant, which t=
o the<br />best of my knowledge is the only one that has been practically d=
emonstrated,<br />an adversary exploits the fee-rate sorting of the INV mes=
sage selection algorithm<br />to jam a pre-signed time-sensitive transactio=
n until timelock expiration. This<br />attack works in jamming transaction-=
relay link between 2 _honest_ full-node peers,<br />where the adversary jus=
t have connections to one of the peer.<br /><br />## Proposed Solution: Str=
ict Validation of Transaction Message Dance<br /><br />In my understanding,=
 all the problems are intersecting on the lack of strict<br />validation of=
 the transaction messages dance (INV &lt;- ; GETDATA -&gt; ; TX), at<br />l=
east as a initial building block for more complete solutions.<br /><br />Th=
ere is a known pratical downside of asserting strict validation of the<br /=
>transaction message dance as one of the property wished to solve the layou=
t<br />problems, namely deployment would break wallets and clients relying =
on "just<br />do a raw TX" relay of transaction (and from browsing some wal=
let libraries,<br />actually some are doing it).<br /><br />Alleviating thi=
s issue, one of the draft BIP proposes to introduce a new<br />versioning o=
f the transaction-relay protocol.<br /><br />Excerpt:<br /><br />```<br /><=
br />Peers supporting the v2 transaction relay protocol signal support by a=
dverstising<br />the 13th bit service flag in the addr p2p messages (`ADDR`=
 and `ADDRV2`).<br /><br />```<br /><br />This is not a perfect solution, a=
s that means non-upgraded peers can still<br />use the open connection slot=
s for this to provoke one of the troubleshoot<br />problems exposed above. =
There is an implementation of this idea that has<br />been opened on bitcoi=
n core, though from the discussions no idea has arised<br />on how to keep =
supporting non-upgraded clients in the less disruptive fashion.<br /><br />=
Eager to gather feedback if alternative solutions can exist instead of intr=
oducing<br />a future v2 transaction-relay protocol.<br /><br />Cheers,<br =
/>Antoine<br />OTS hash: 5d0bbfd70054e5075a27058f53046108658b9b032ec4fa81ff=
6741a45b8a051d<br /><br />[0] https://github.com/bitcoin/bips/pull/1663<br =
/>[1] https://github.com/bitcoin/bips/pull/1664<br />[2] https://gnusha.org=
/pi/bitcoindev/CALZpt+E6UqB5cew145PO2qiEMsELJ-TuGyE5PBL04T1tESiOiQ@mail.gma=
il.com/<br />[3] https://github.com/bitcoin/bitcoin/issues/31033<br />[4] h=
ttps://github.com/bitcoin/bitcoin/pull/30572<br />[5] https://groups.google=
.com/g/bitcoindev/c/GuS36ldye7s<br /><br />

<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/e98ec3a3-b88b-4616-8f46-58353703d206n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/e98ec3a3-b88b-4616-8f46-58353703d206n%40googlegroups.com</a>.<br />

------=_Part_221733_1007132400.1739936209062--

------=_Part_221732_156492301.1739936209062--