From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 18 Nov 2025 16:06:09 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vLVi4-0004kp-EN for bitcoindev@gnusha.org; Tue, 18 Nov 2025 16:06:09 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3e1383751f1sf527173fac.1 for ; Tue, 18 Nov 2025 16:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1763510762; x=1764115562; 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=xpXIoIbNUr6r77pLL8Rzoyt0HFAtTNiLAl9uicoc61U=; b=GS+4LTWNIFWmHO83vBy/hsWxUmzEWmBhk1Kq9sfM3VTVdpOkyVMMNzhAkxJQ4+DpaE jt4W7u8x0aFBx5bG7wyExTfNdAKhIadbUQ2waFENEkmUxEgJkEjJhlsmvCyMfJZQAf1O XBuBwtAZTetS+3eXi1dT/jeEl3QBhGg7GMtBIM2HGGkSq4408oItxRYG3XKVN8EoFkvq v1zGia7Ez0UKHcCeFNImadbVDfrYEBaTOWULMuDAJvruR8JFZ3TebnXXexLD2vmrggWj dlG2rhK7YNyWayfUw1j52UDziFb305TZGA1QZCDzwdNwn5O7WZ+CmlPtrn5LEKDnXBn2 pClw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763510762; x=1764115562; 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=xpXIoIbNUr6r77pLL8Rzoyt0HFAtTNiLAl9uicoc61U=; b=UY/U2Rmoz/JEL9czV5RVq3YTchV7nsVzonndZeh4g4GpCT7iLiBvzRD6Iu5tZKfFKP 6b8uoyzmtE6UaK3f/kOQqisUiKduwyqx7Qky+kR5PczkIX7i/Mx/VSvEMPBBOU3N1R0r 4XW/S5mvSvEa5Ak90MSymUDt1+kNO5zRLVgqLwK9BW6PThJBOTCWeCXWdIAqX4KHyjXu Jp4cnTC7Fsk4csPD01cP/MpNkFniDHNFQ1+fvluAibzC3XRIqiIR2plEuf9XSl9qzMpC UpYYHvtKRGit0D4p5R6y3W9B/lLvP5Ocs8dGtBzMe0N7VfFQtLlDeul8//KxfUZ2YUIh GtmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763510762; x=1764115562; 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=xpXIoIbNUr6r77pLL8Rzoyt0HFAtTNiLAl9uicoc61U=; b=CBn2w9vmrxcbcO0bHDpMgGUP/45I6H/CY1QkW/F97B3ICVVDpV3bdFfEKkjS3xROSA obpvOHKuxCJz/7d0joL4YH7N7eBkJZZvoY3TSINC0Lzl8xxPxiw3ANjH92YIbmSBojuk Q+YmyVl9gX92imrmJKkgdI2xDERAnBak6u8FfUvX6Zs1As5Yy2zGmlqMxKwDQJv4tJvh 09BgcGCDY/B0jn/u7ow6ObK2NrD/AMYr+eZ4bFjjMbh/w1Nvp8n9Trnj7g7qgYSPNR0z qWTJKi5Pv5rC37k793ZeOuEQBH+cXMEoVEeKTiiAmj9bIhIIL44gRNfHKz57zFHyt9eX 7o8A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXfieTGOcdqaXYuxZXJmXqjR8G9w2X2rA0J8DYqpl1PadMN9EfTmO4QSu63SOr6/c/Vbx+BaxcYs+WJ@gnusha.org X-Gm-Message-State: AOJu0Yxs2st/WxUUwq1YR3+8eDgWh0iVWIDDXPF3yQshTCkSYBVf7KfA oMG7Y4hf8U0EdRqGECJ6+MwTk8oJVyI2e7y83VX7MtFzsLEHhCx88kmi X-Google-Smtp-Source: AGHT+IE4vBejDYVcWntkV1tkGqZxv2mWt8/Tz2mWG643mkIpFGrDZ157Luj/MYStfYEuJDbv1avtJA== X-Received: by 2002:a05:6870:d38c:b0:3e8:9e80:d06c with SMTP id 586e51a60fabf-3ec8368c4c3mr237360fac.25.1763510761962; Tue, 18 Nov 2025 16:06:01 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Yvv0xftiS0BxQ7ndeiqS0yG7xxL0HcBgkS1MrENm8otw==" Received: by 2002:a05:6870:2499:b0:3ec:3f46:13ce with SMTP id 586e51a60fabf-3ec3f46157als1503518fac.0.-pod-prod-06-us; Tue, 18 Nov 2025 16:05:56 -0800 (PST) X-Received: by 2002:a05:6808:13c4:b0:450:125d:d9e with SMTP id 5614622812f47-45097457570mr8895782b6e.21.1763510756422; Tue, 18 Nov 2025 16:05:56 -0800 (PST) Received: by 2002:a05:690c:4042:b0:785:e55d:2dfd with SMTP id 00721157ae682-78a6bfa4f22ms7b3; Tue, 18 Nov 2025 16:01:34 -0800 (PST) X-Received: by 2002:a05:690c:380a:b0:786:9774:a39c with SMTP id 00721157ae682-78929e3f0cbmr149357007b3.9.1763510493745; Tue, 18 Nov 2025 16:01:33 -0800 (PST) Date: Tue, 18 Nov 2025 16:01:33 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <299d4f39-b8cd-4736-b6bb-71def4d85f74n@googlegroups.com> Subject: [bitcoindev] New bitcoin backbone code release + Tx relay v2 update MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_173970_261664584.1763510493406" 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_173970_261664584.1763510493406 Content-Type: multipart/alternative; boundary="----=_Part_173971_1464888178.1763510493406" ------=_Part_173971_1464888178.1763510493406 Content-Type: text/plain; charset="UTF-8" Hello devs, Shared new code for bitcoin backbone available on the website (bitcoinbackbone.org). Biggest changes from latest release has been mostly working on BIP324 re-implementation, cleaning bugs implementing a simple tx-relay stack, a little mempoool buffer and some groundworks on address management. Tx syncing works with vanilla bitcoin core v0.30 software. I did a layout of the process architecture on the website, but the mempool is fully living in its own mempool process, fully separate from the block pipeline. In case of mempool DoS for whatever reasons, the full-node keeps processing blocks. This also opens the door to have *multiple* mempools with incompatible policies among themselves, and just select the highest fees paying graph of consensus-valid transactions, after sanitizing out conflicts. As I was writing in my latest email about bitcoin backbone, of course there are some trade-offs with the mempool not living in the same memory space than the validation engine, though I think you have practical improvements on this area. The simple tx-relay stack also implements a basic implementation of the proposed overhaul of the tx-relay v2 [0]. Currently, the tx flow is INV(txid) -> ; <- GETDATA(inv(txid)) ; TX(tx) -> . With the proposed tx-relay v2 overhaul, if an INV for the txid has not previously received for the transaction, i.e the transaction processing has not been requested, the transaction is strictly rejected, without further processing. This more stricter tx processing can be activated with a setting option in bitcoin backbone. Long-term, I think some form of tx-relay link-level mitigation is a strong necessity to diminish the surface attack of time-sensitive contracting protocol in face of tx-relay throughput overflow, where a malicious peer is buying out your full-node tx bandwidth to tamper with the propagation of a time-sensitive tx (e.g a lightning's HTLC-preimage) [1]. The day we wish to improve time-sensitive second-layers tx-propagation security, it might take time to have network-wide upgrade of the full-node and wallets participating in tx-relay (you have deployment transition problem, where traffic from non-upgraded tx-relay clients can be used to jam the outgoing traffic of upgraded tx-relay nodes or clients). So doing a heads up on that sounds wise, there are clearly well-used wallet library that have never respected the INV -> ; <- GETDATA ; TX -> relay flow [2] [3] Finishing to have Erlay support in bitcoin backbone, then I'll work on a more refined version of the tx-relay V2 protocol proposal, because current version of the draft proposal on the BIP repo is silent on advanced tx synchronization protocols. This is still mostly a very toy full-node but it's taking shape. Keep building. Cheers, Antoine OTS hash: 79ae6e1fda391d3aa44d36f26acb32b3871d01543037d467a8210e4e96c972a8 [0] https://groups.google.com/g/bitcoindev/c/PkNlRu1ylX4 [1] https://groups.google.com/g/bitcoindev/c/GuS36ldye7s [2] E.g bitcoinj https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L178 [3] Dropping unrequested transaction is only one approach on mitigating that, but a simple first building block on which more sophisticated mitigation strategies can be built. -- 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/299d4f39-b8cd-4736-b6bb-71def4d85f74n%40googlegroups.com. ------=_Part_173971_1464888178.1763510493406 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello devs,

Shared new code for bitcoin backbone available on th= e website
(bitcoinbackbone.org). Biggest changes from latest release h= as
been mostly working on BIP324 re-implementation, cleaning bugs
implementing a simple tx-relay stack, a little mempoool buffer
and so= me groundworks on address management. Tx syncing works with
vanilla bi= tcoin core v0.30 software.

I did a layout of the process archite= cture on the website, but the
mempool is fully living in its own mempo= ol process, fully separate
from the block pipeline. In case of mempool= DoS for whatever reasons,
the full-node keeps processing blocks. This= also opens the door to
have *multiple* mempools with incompatible pol= icies among themselves,
and just select the highest fees paying graph = of consensus-valid
transactions, after sanitizing out conflicts.
=
As I was writing in my latest email about bitcoin backbone, of course=
there are some trade-offs with the mempool not living in the same mem= ory
space than the validation engine, though I think you have practica= l
improvements on this area.

The simple tx-relay stack also= implements a basic implementation of the
proposed overhaul of the tx-= relay v2 [0]. Currently, the tx flow is
INV(txid) -> ; <- GETDAT= A(inv(txid)) ; TX(tx) -> . With the proposed tx-relay
v2 overhaul, = if an INV for the txid has not previously received for the
transaction= , i.e the transaction processing has not been requested, the
transacti= on is strictly rejected, without further processing. This more
stricte= r tx processing can be activated with a setting option in bitcoin
back= bone.

Long-term, I think some form of tx-relay link-level mitiga= tion is a strong
necessity to diminish the surface attack of time-sens= itive contracting
protocol in face of tx-relay throughput overflow, wh= ere a malicious peer
is buying out your full-node tx bandwidth to tamp= er with the propagation
of a time-sensitive tx (e.g a lightning's HTLC= -preimage) [1].

The day we wish to improve time-sensitive second= -layers tx-propagation
security, it might take time to have network-wi= de upgrade of the full-node
and wallets participating in tx-relay (you= have deployment transition
problem, where traffic from non-upgraded t= x-relay clients can be used to
jam the outgoing traffic of upgraded tx= -relay nodes or clients). So doing
a heads up on that sounds wise, the= re are clearly well-used wallet library
that have never respected the = INV -> ; <- GETDATA ; TX -> relay flow [2] [3]

Finishin= g to have Erlay support in bitcoin backbone, then I'll work on a more
= refined version of the tx-relay V2 protocol proposal, because current versi= on
of the draft proposal on the BIP repo is silent on advanced tx sync= hronization
protocols.

This is still mostly a very toy full= -node but it's taking shape.

Keep building.

Cheers,Antoine
OTS hash: 79ae6e1fda391d3aa44d36f26acb32b3871d01543037d467= a8210e4e96c972a8

[0] https://groups.google.com/g/bitcoindev/c/Pk= NlRu1ylX4
[1] https://groups.google.com/g/bitcoindev/c/GuS36ldye7s
[2] E.g bitcoinj https://github.com/bitcoinj/bitcoinj/blob/master/core/sr= c/main/java/org/bitcoinj/core/TransactionBroadcast.java#L178
[3] Dropp= ing unrequested transaction is only one approach on mitigating that,
b= ut a simple first building block on which more sophisticated mitigation str= ategies
can be built.

--
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/299d4f39-b8cd-4736-b6bb-71def4d85f74n%40googlegroups.com.
------=_Part_173971_1464888178.1763510493406-- ------=_Part_173970_261664584.1763510493406--