diff options
author | Antoine Riard <antoine.riard@gmail.com> | 2025-02-18 19:36:49 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-02-23 12:07:09 -0800 |
commit | 6319aa090ec9456816f94991f0afa00a7673cb48 (patch) | |
tree | 771dfe553f7bc127ffd706ac1e150b48945d217f | |
parent | 4f8098abbaad51c166df10040183cc50911606d2 (diff) | |
download | pi-bitcoindev-6319aa090ec9456816f94991f0afa00a7673cb48.tar.gz pi-bitcoindev-6319aa090ec9456816f94991f0afa00a7673cb48.zip |
[bitcoindev] Update on Transaction Relay V2
-rw-r--r-- | cc/b53e4b831ab79c06a2bcaa4004ed1712792d52 | 302 |
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 <- ; GETDATA -> ; 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" 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-- + |