summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAntoine Riard <antoine.riard@gmail.com>2025-02-18 19:36:49 -0800
committerbitcoindev <bitcoindev@googlegroups.com>2025-02-23 12:07:09 -0800
commit6319aa090ec9456816f94991f0afa00a7673cb48 (patch)
tree771dfe553f7bc127ffd706ac1e150b48945d217f
parent4f8098abbaad51c166df10040183cc50911606d2 (diff)
downloadpi-bitcoindev-6319aa090ec9456816f94991f0afa00a7673cb48.tar.gz
pi-bitcoindev-6319aa090ec9456816f94991f0afa00a7673cb48.zip
[bitcoindev] Update on Transaction Relay V2
-rw-r--r--cc/b53e4b831ab79c06a2bcaa4004ed1712792d52302
1 files changed, 302 insertions, 0 deletions
diff --git a/cc/b53e4b831ab79c06a2bcaa4004ed1712792d52 b/cc/b53e4b831ab79c06a2bcaa4004ed1712792d52
new file mode 100644
index 000000000..17c7bce75
--- /dev/null
+++ b/cc/b53e4b831ab79c06a2bcaa4004ed1712792d52
@@ -0,0 +1,302 @@
+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--
+