From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 07 Aug 2025 02:02:16 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ujwVs-0005op-4D for bitcoindev@gnusha.org; Thu, 07 Aug 2025 02:02:16 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-30b86163fe0sf1407878fac.0 for ; Thu, 07 Aug 2025 02:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1754557329; x=1755162129; 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=f8ICpYoeJGLw9E76tXex9qWg4uMN8bHBfNzz7oIJSHE=; b=q/poK76gnHz3M6WyMHifCCvaBUsyOXi3ZCuly56jZtCmkUey7dlTrWCAF2Gbearx/m 6mgwD/KWex7kOS5oFwd0Y6X78ehd1ngIKLs+BE0FefE1eimunSKIQlWxeSFE9/yHz2eE JvJv9dorbJMW5rtzNCB259eIfTxmsZ0BJXLWL6kgRa3GX/vh7iQdXTX2N/SLDMs09WSZ XdUc4UYSNuA2iBpQEPRcMSOxxUW/6lEm0rD0PD1n3Qfdlx5Mppm+dpHgG1ih4h03vYn2 C+uw/JFwV2zebf11urJ3U/1W0bH/b9jprrscwhTAvpNsgJ1G8g1KLXtqWMBze0jWU+pA gI/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754557329; x=1755162129; 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=f8ICpYoeJGLw9E76tXex9qWg4uMN8bHBfNzz7oIJSHE=; b=XDqcLUTB+e9Z8914sydZsb3+d0cpCHNwqoprEmSE+8D9hlvF68DgjyhQRkQgdwFMCd aJQbG3WJazjz2xqhn7lgx8uGf94hPRuhdHZCXzyjZNVijDu1+iohx5Pi0qTrVUwNkMy4 cS1Y19kPBCm0P6YTN3bXEBowXXAXJFD9ZpYDWX3V+wR9nTrm52X5xD/+0zi3CNUiN+7g hDMcbXcomaODpWZoNIwGb7ZJKm5hwdzvXYGVKGty2BweL0i5yF6KQvmYiWVv/6L49K68 y1otSefeCHInFsHj3Ru4mQRyykjdhplyeRbVIMT//STgDUU2PTSNDLZKCwSESLxJyK/e DClw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754557329; x=1755162129; 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=f8ICpYoeJGLw9E76tXex9qWg4uMN8bHBfNzz7oIJSHE=; b=Bej+eVcs28ri/He2ATEbcFACPciFLG6oTrjdTNCjF9t4RB0PRXJM+xMsPwy9pKHAuS gDJgwZ3CkiIjXwAUk2aPBmsIfVmcT5+tdYNFXNDFRa+WkZm/mQRV4lPozJcfxCSbbYl0 n0WwqIYW8uoZ4lU7IY0HkocVi7yWc6UadNPacBoxRP/ZquBvG9eh4qJcbGIxz+gRsz7z XZYuS4sfUO8vqZZ/iYq6WrOYTcfXzgAuFRHWnwjXLInSTzOD6oFiLqtUWQ8aUlahDRrs cYpLD09z2wj4svju1VgpaCIzAvEnj21+STWRdrmYG8I4Bf/gFWV+/8l720NRTHvPsRf6 pgZA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXgQF4PXeg4ksRbIU8Uf8cvM0V0XKISuwDQsiZOwFEAL+DMYg3osfWCl2Z2hAGymYolVn6AODutYsWO@gnusha.org X-Gm-Message-State: AOJu0YxwMru5iMTSCSly2u60gJbc1aDUZscoJUvF963GyqeAIEYTI6Nq /TXCW+sYr/e254p3fGDSEqEg/ymsn1e70BFds6PYjv90dKSKzKJ0F5vH X-Google-Smtp-Source: AGHT+IHbPzU6UEubXt0XQIKza9As5BrUoqGQwbjTNn/MNKGUHH4N9EcRGFR4jqKAyeS6Cnh40t7acg== X-Received: by 2002:a05:6871:5820:b0:306:9f1d:da2a with SMTP id 586e51a60fabf-30c0191cec7mr1673397fac.5.1754557329342; Thu, 07 Aug 2025 02:02:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfLBya+zyYDdd/wsm0qOpxNf3AZxbeCUtLWi9thKxRn8w== Received: by 2002:a05:6870:1294:b0:30b:d6e4:3de6 with SMTP id 586e51a60fabf-30bfe789211ls250354fac.2.-pod-prod-01-us; Thu, 07 Aug 2025 02:02:05 -0700 (PDT) X-Received: by 2002:a05:6808:5090:b0:434:1019:89cb with SMTP id 5614622812f47-435885220c1mr1363231b6e.2.1754557325317; Thu, 07 Aug 2025 02:02:05 -0700 (PDT) Received: by 2002:a05:690c:ed6:b0:71a:913:f75c with SMTP id 00721157ae682-71bcd5ca06fms7b3; Thu, 7 Aug 2025 01:36:32 -0700 (PDT) X-Received: by 2002:a05:690c:4d46:b0:71a:198a:217f with SMTP id 00721157ae682-71bdbb822efmr32420657b3.8.1754555791246; Thu, 07 Aug 2025 01:36:31 -0700 (PDT) Date: Thu, 7 Aug 2025 01:36:30 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn@googlegroups.com> Subject: [bitcoindev] Feedbacks on libbitcoinkernel & bitcoin backbone MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_28676_1723525879.1754555790741" 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_28676_1723525879.1754555790741 Content-Type: multipart/alternative; boundary="----=_Part_28677_1886067042.1754555790741" ------=_Part_28677_1886067042.1754555790741 Content-Type: text/plain; charset="UTF-8" Hi, Sharing the code for a small side project of mine, bitcoin backbone a natively multi process full node written in rust, wrapping the core's libbitcoinkernel (v27.0 iirc). This is full demo code for now, though it got to the point where blocks can be downloaded from a vanilla bitcoind peer and the heap of C / Rust / CPP code built correctly on both ARM (Darwin) and x86_64 (Debian 12) platforms. The whole build system is still a huge bunch of dirty hacks, but it's done without binding generator or whatever. That's good to keep the build toolchain strictly minimal. Architecture is for now one main process (`backbone`) running the libbitcoinkernel and orchestrating connections with traffic network dedicated process (`block-relay` and `addr-relay`). Configurations is very basic and I've not tested on all networks so far (reg, main, test, etc). Code can be download here (head commit 689e9df60) git clone git://bitcoinbackbone.org:/public-release.git Few lines of feedbacks on the libbitcoinkernel. First and foremost, a pure C API is very fruitful for crossing the boundaries between the different langages memory model. While in theory, you can e.g write your CPP code in Rust code, in practice a lot of CPP abstractions doesn't map well equivalently in Rust (--or whatever other langs). For now, hacked a custom C API on top of the libbitcoinkernel with basic block processing and chainman init/shutdown, though the ideal one would keep all the state on the CPP side. And allow multi-threaded code access on top. Second, while writing the block-relay process I figure out that for some data structs one might be willing to check the syntax structure of the headers by calling the libbitcoinkernel methods as pre-checks __before_ to pass full blocks to the main validation one. So you could have multiple same-version shared libbitcoinkernel code in you're different process, one with the chain state the other "empty". That way you can verify a subset of the consensus rule, without re-implementing the rules in your other lang, at the risk of f*kcing them up or deviating. Third, I've not starrted really to work on tx-relay, but there is the question of validating at some moment the transactions you're receiving against the spent UTXO to verify the "spent" UTXOs are indeed part of your latest validated UTXO sets. In a multi-process setup, this UTXO set state might not be fully live in the same memory space and there are indeed challenge to that correctly. There are few hacks I'm brooding on, in the style of utreexo, though here you don't need proofs as it's in the same "full node" boundary. It's an interesting question. Keep building. Cheers, Antoine OTS hash: 3c8c398a8730539303767a20b1408dd887cb955ae9d602590c57277dd52f645f -- 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/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn%40googlegroups.com. ------=_Part_28677_1886067042.1754555790741 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,

Sharing the code for a small side project of mine, bitcoin b= ackbone
a natively multi process full node written in rust, wrapping t= he core's
libbitcoinkernel (v27.0 iirc). This is full demo code for no= w, though
it got to the point where blocks can be downloaded from a va= nilla bitcoind
peer and the heap of C / Rust / CPP code built correctl= y on both ARM
(Darwin) and x86_64 (Debian 12) platforms. The whole bu= ild system is
still a huge bunch of dirty hacks, but it's done without= binding generator
or whatever. That's good to keep the build toolchai= n strictly minimal.

Architecture is for now one main process (`b= ackbone`) running the
libbitcoinkernel and orchestrating connections w= ith traffic network
dedicated process (`block-relay` and `addr-relay`)= . Configurations
is very basic and I've not tested on all networks so = far (reg, main,
test, etc).

Code can be download here (head= commit 689e9df60)

git clone git://bitcoinbackbone.org:/public-r= elease.git

Few lines of feedbacks on the libbitcoinkernel. First= and foremost,
a pure C API is very fruitful for crossing the boundari= es between
the different langages memory model. While in theory, you c= an e.g
write your CPP code in Rust code, in practice a lot of CPP abst= ractions
doesn't map well equivalently in Rust (--or whatever other la= ngs). For
now, hacked a custom C API on top of the libbitcoinkernel wi= th basic
block processing and chainman init/shutdown, though the ideal= one
would keep all the state on the CPP side. And allow multi-threade= d
code access on top.

Second, while writing the block-relay= process I figure out that
for some data structs one might be willing = to check the syntax
structure of the headers by calling the libbitcoi= nkernel methods
as pre-checks __before_ to pass full blocks to the mai= n validation
one. So you could have multiple same-version shared libbi= tcoinkernel
code in you're different process, one with the chain state= the other
"empty". That way you can verify a subset of the consensus = rule, without
re-implementing the rules in your other lang, at the ris= k of f*kcing them
up or deviating.

Third, I've not starrted= really to work on tx-relay, but there is the
question of validating a= t some moment the transactions you're receiving
against the spent UTX= O to verify the "spent" UTXOs are indeed part of
your latest validated= UTXO sets. In a multi-process setup, this UTXO set
state might not be= fully live in the same memory space and there are
indeed challenge to= that correctly. There are few hacks I'm brooding on,
in the style of = utreexo, though here you don't need proofs as it's in
the same "full n= ode" boundary. It's an interesting question.

Keep building.

Cheers,
Antoine
OTS hash: 3c8c398a8730539303767a20b1408dd8= 87cb955ae9d602590c57277dd52f645f

--
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/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn%40googlegroups.com.
------=_Part_28677_1886067042.1754555790741-- ------=_Part_28676_1723525879.1754555790741--