Delivery-date: Sun, 20 Oct 2024 00:01:20 -0700
Sender: bitcoindev@googlegroups.com
Date: Sat, 19 Oct 2024 23:56:06 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <62313198-398b-42a5-92bd-dfcc57434d55n@googlegroups.com>
Subject: [bitcoindev] On Libbitcoinkernel Readyness
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_185290_71853483.1729407366229"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_185290_71853483.1729407366229
Content-Type: multipart/alternative; 
	boundary="----=_Part_185291_2129285624.1729407366229"

------=_Part_185291_2129285624.1729407366229
Content-Type: text/plain; charset="UTF-8"

Hello list,

During the summer, I hacked a bit on the bitcoind build system and the
libbitcoinkernel projects to see how far it was ready to be used on its
own. Personally, I've always been interested to run the historical bitcoin
consensus engine on its own only in secure enclave to reduce the exposure
surface and this enclave only getting transactions and blocks [0].

As a reminder for the libbitcoinerkernel, for the folks who are less
familiar with this project, see the following [1] [2].

The current way of using libbitcoinerkernel is a bit shaggy for now,
especially if you don't have experience with build systems on embedded
systems, so for whom can be interested, I made a public an extraction
of the libbitcoinkernel files and with a working build system in a
standalone repository.

https://github.com/ariard/standalone-bitcoinkernel

Of course, this has been to have been tested on all the *nix, or
a bunch of different ISAs, though normally it compiles quite good.
I believed it could be interesting for people who wish to re-write
their own full-node or wrapped it as component for other usage in
the bitcoin stack. Doing those, without having to re-write from
scratch a compatible consensus engine, bug for bug.

Either using the C++ api or linking against the static library
directly is probably very rough, though if there are already
full-node implementation in go, cpp or whatever another language,
maybe it's mature enough for them to experiment or test it as a
"monitor" consensus engine to check there is no differential in
block validation with their current consensus engine. I'll see to
peg that standalone consensus engine utility with some rust code to
see how it looks like.

If you find bugs in the build system or around the C++ validation
interface, please be nice and report them accordingly.

Cheers,
Antoine
ots hash: a50ace52cfabade91d0fbb95f824a5f9607a251cdf8c4d34381ea2d86725bef5

[0] 
https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/188
[1] https://github.com/bitcoin/bitcoin/issues/24303
[2] 
https://bitcoin.stackexchange.com/questions/113863/in-future-will-multiple-widely-used-implementations-around-libbitcoinkernel-be-a

-- 
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/62313198-398b-42a5-92bd-dfcc57434d55n%40googlegroups.com.

------=_Part_185291_2129285624.1729407366229
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello list,<br /><br />During the summer, I hacked a bit on the bitcoind bu=
ild system and the<br />libbitcoinkernel projects to see how far it was rea=
dy to be used on its<br />own. Personally, I've always been interested to r=
un the historical bitcoin<br />consensus engine on its own only in secure e=
nclave to reduce the exposure<br />surface and this enclave only getting tr=
ansactions and blocks [0].<br /><br />As a reminder for the libbitcoinerker=
nel, for the folks who are less<br />familiar with this project, see the fo=
llowing [1] [2].<br /><br />The current way of using libbitcoinerkernel is =
a bit shaggy for now,<br />especially if you don't have experience with bui=
ld systems on embedded<br />systems, so for whom can be interested, I made =
a public an extraction<br />of the libbitcoinkernel files and with a workin=
g build system in a<br />standalone repository.<br /><br />https://github.c=
om/ariard/standalone-bitcoinkernel<br /><br />Of course, this has been to h=
ave been tested on all the *nix, or<br />a bunch of different ISAs, though =
normally it compiles quite good.<br />I believed it could be interesting fo=
r people who wish to re-write<br />their own full-node or wrapped it as com=
ponent for other usage in<br />the bitcoin stack. Doing those, without havi=
ng to re-write from<br />scratch a compatible consensus engine, bug for bug=
.<br /><br />Either using the C++ api or linking against the static library=
<br />directly is probably very rough, though if there are already<br />ful=
l-node implementation in go, cpp or whatever another language,<br />maybe i=
t's mature enough for them to experiment or test it as a<br />"monitor" con=
sensus engine to check there is no differential in<br />block validation wi=
th their current consensus engine. I'll see to<br />peg that standalone con=
sensus engine utility with some rust code to<br />see how it looks like.<br=
 /><br />If you find bugs in the build system or around the C++ validation<=
br />interface, please be nice and report them accordingly.<br /><br />Chee=
rs,<br />Antoine<br />ots hash: a50ace52cfabade91d0fbb95f824a5f9607a251cdf8=
c4d34381ea2d86725bef5<br /><br />[0] https://gitlab.com/lightning-signer/va=
lidating-lightning-signer/-/issues/188<br />[1] https://github.com/bitcoin/=
bitcoin/issues/24303<br />[2] https://bitcoin.stackexchange.com/questions/1=
13863/in-future-will-multiple-widely-used-implementations-around-libbitcoin=
kernel-be-a<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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/62313198-398b-42a5-92bd-dfcc57434d55n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/62313198-398b-42a5-92bd-dfcc57434d55n%40googlegroups.com</a>.=
<br />

------=_Part_185291_2129285624.1729407366229--

------=_Part_185290_71853483.1729407366229--