1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
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 <bitcoindev+bncBC3PT7FYWAMRBDOX2HCAMGQEAFZCAFI@googlegroups.com>)
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 <bitcoindev@gnusha.org>; 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 <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <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_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,<br /><br />Sharing the code for a small side project of mine, bitcoin b=
ackbone<br />a natively multi process full node written in rust, wrapping t=
he core's<br />libbitcoinkernel (v27.0 iirc). This is full demo code for no=
w, though<br />it got to the point where blocks can be downloaded from a va=
nilla bitcoind<br />peer and the heap of C / Rust / CPP code built correctl=
y on both ARM <br />(Darwin) and x86_64 (Debian 12) platforms. The whole bu=
ild system is<br />still a huge bunch of dirty hacks, but it's done without=
binding generator<br />or whatever. That's good to keep the build toolchai=
n strictly minimal.<br /><br />Architecture is for now one main process (`b=
ackbone`) running the<br />libbitcoinkernel and orchestrating connections w=
ith traffic network<br />dedicated process (`block-relay` and `addr-relay`)=
. Configurations<br />is very basic and I've not tested on all networks so =
far (reg, main,<br />test, etc).<br /><br />Code can be download here (head=
commit 689e9df60)<br /><br />git clone git://bitcoinbackbone.org:/public-r=
elease.git<br /><br />Few lines of feedbacks on the libbitcoinkernel. First=
and foremost,<br />a pure C API is very fruitful for crossing the boundari=
es between<br />the different langages memory model. While in theory, you c=
an e.g<br />write your CPP code in Rust code, in practice a lot of CPP abst=
ractions<br />doesn't map well equivalently in Rust (--or whatever other la=
ngs). For<br />now, hacked a custom C API on top of the libbitcoinkernel wi=
th basic<br />block processing and chainman init/shutdown, though the ideal=
one<br />would keep all the state on the CPP side. And allow multi-threade=
d<br />code access on top.<br /><br />Second, while writing the block-relay=
process I figure out that<br />for some data structs one might be willing =
to check the syntax <br />structure of the headers by calling the libbitcoi=
nkernel methods<br />as pre-checks __before_ to pass full blocks to the mai=
n validation<br />one. So you could have multiple same-version shared libbi=
tcoinkernel<br />code in you're different process, one with the chain state=
the other<br />"empty". That way you can verify a subset of the consensus =
rule, without<br />re-implementing the rules in your other lang, at the ris=
k of f*kcing them<br />up or deviating.<br /><br />Third, I've not starrted=
really to work on tx-relay, but there is the<br />question of validating a=
t some moment the transactions you're receiving <br />against the spent UTX=
O to verify the "spent" UTXOs are indeed part of<br />your latest validated=
UTXO sets. In a multi-process setup, this UTXO set<br />state might not be=
fully live in the same memory space and there are<br />indeed challenge to=
that correctly. There are few hacks I'm brooding on,<br />in the style of =
utreexo, though here you don't need proofs as it's in<br />the same "full n=
ode" boundary. It's an interesting question.<br /><br />Keep building.<br /=
><br />Cheers,<br />Antoine<br />OTS hash: 3c8c398a8730539303767a20b1408dd8=
87cb955ae9d602590c57277dd52f645f
<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/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn%40googlegroups.com</a>.<br />
------=_Part_28677_1886067042.1754555790741--
------=_Part_28676_1723525879.1754555790741--
|
