From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 20 Oct 2024 00:01:20 -0700 Received: from mail-yw1-f185.google.com ([209.85.128.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t2PwG-00032s-2z for bitcoindev@gnusha.org; Sun, 20 Oct 2024 00:01:20 -0700 Received: by mail-yw1-f185.google.com with SMTP id 00721157ae682-6e3231725c9sf61501477b3.1 for ; Sun, 20 Oct 2024 00:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1729407673; x=1730012473; 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=TaihkwHPS6XLGjJ5ilMEwfMi4wLqaHAYQSh4ACBcGJ4=; b=Xx5eJ/nMaicGRZO9BUNDo+WmKzZ6aYd8R4T6qualNKRlGEmM8SLKwVlZw8pZaKT8sb hW7Jhu2alkkpXiNtamG8GGO3a8FifYHnbbcsJkuTPJgz+Rn8DjAIlyO0tGvC3WewmmTE GhsB5zgbwTgF/QTVosx16K+UpYLIz0bNZlW7wTk7q5YpoU/6Q5nMx6l98Vg0m+Lv8Xlh NAlKownrMy3nhSXGCHclLcgorD9J8nkgTWzNm0KOFmIF/fv0V4JlEj8VjbIl2uThKnT7 JRsxagDh2Z5xwg+qCaC69XNYwvSqdCQrQi822cGSLI3lKaio21Wgou0KnBSPPDsmuTr3 WUzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729407673; x=1730012473; 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=TaihkwHPS6XLGjJ5ilMEwfMi4wLqaHAYQSh4ACBcGJ4=; b=c9Dfydz3tKtupOHb1KmLNDg40jDIX8K7tXEJk+bCkfUdwydgb7S71DsBb3nQTppCzf aKukeXWNQ+oFfx6uV3vnrptXE8AtROn/1Ec7h+5TVuJTT8PhkdGFi++ZJZ/OTmuTVjAD dM/yx0m9d7ITlRRAUJXrsAzILgavHZepBHfCvdhRqL+li8/I3HbVfFbWFtM+cG7wKH0j cT4FfFOzrp9o90mGbqY+16XQ1Rcm3zJIFZzcp3/tVlXUHTCcm5OoK+mPAPNvpi76Hg4F OAtHzWeQvWNzl/ihSLMLBCT1vOePgGdt+Yim0xdxn+u9E8L+jlFMqULLpli8Hh9Nwl0U sJzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729407673; x=1730012473; 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=TaihkwHPS6XLGjJ5ilMEwfMi4wLqaHAYQSh4ACBcGJ4=; b=HIrIAT5NrcfcY9NPgenUU5PKmHZE3Qh7hrVAUM4MprxIQFru+g9/Fhdiyy/Gk9glBd crok/M3ICU3PRpMmZpRENAHLKe19VasA8uKncnsQYdjzwWITYhxkHA0ou9gyZPNnbl36 WyL/FSOPX5L73e9yCk2rAkC1QezRxLDXyd3wX5uSGcMrcmawn0AVyeWK0MylSIL9vl5F 0G5lQNFE9O/L8l+tl0j9R7WHuAR2AEBgNLOZ0FTTAtpsPxX/JCTTY6+WW+eOqA1dnW8i BtoBw+mt+hgRTKrzRmHgh6hA9t+KkZduCafHPtehpLz12w+n+M3rBZNwdvkzc43BbhEm /axA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUelJjBv0FzHQOWBD4Bcd9KtPK25MV1fGhCmkHCqByjZ/hEiFY/g+2UaAf9NiKltKCE1WOp2JIGKuFY@gnusha.org X-Gm-Message-State: AOJu0YzTpa4vbcNOfTaprZT3DAYBNa1WCRLQBeW6O8U1h2BWcqWfa6d4 TFzJtCpVOCii4jjSEkbx86m6Oni2Ryhx5LsFqAiylFQnqF4aOzrj X-Google-Smtp-Source: AGHT+IEaNttzL0qU2U35DUsyfZ5GBGTZSgShVmbPCzbRdUwggrSE+/wArXOlq4pX/UTlBRHM1AbM1g== X-Received: by 2002:a05:690c:4249:b0:6e3:2cfb:9a86 with SMTP id 00721157ae682-6e5bf9ff1a9mr55639367b3.26.1729407673543; Sun, 20 Oct 2024 00:01:13 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:154d:b0:e28:67be:7472 with SMTP id 3f1490d57ef6-e2b9cdec56els312512276.1.-pod-prod-05-us; Sun, 20 Oct 2024 00:01:10 -0700 (PDT) X-Received: by 2002:a05:690c:250b:b0:6e3:d31:cdca with SMTP id 00721157ae682-6e5bfcaff1bmr55945327b3.19.1729407670617; Sun, 20 Oct 2024 00:01:10 -0700 (PDT) Received: by 2002:a05:690c:3391:b0:6dd:f386:13dc with SMTP id 00721157ae682-6e5bd64d099ms7b3; Sat, 19 Oct 2024 23:56:07 -0700 (PDT) X-Received: by 2002:a05:690c:9c0a:b0:6e2:c962:75e with SMTP id 00721157ae682-6e5bfc0e0b1mr81026247b3.32.1729407366475; Sat, 19 Oct 2024 23:56:06 -0700 (PDT) Date: Sat, 19 Oct 2024 23:56:06 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List 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" 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_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,

During the summer, I hacked a bit on the bitcoind bu= ild system and the
libbitcoinkernel projects to see how far it was rea= dy to be used on its
own. Personally, I've always been interested to r= un the historical bitcoin
consensus engine on its own only in secure e= nclave to reduce the exposure
surface and this enclave only getting tr= ansactions and blocks [0].

As a reminder for the libbitcoinerker= nel, for the folks who are less
familiar with this project, see the fo= llowing [1] [2].

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

https://github.c= om/ariard/standalone-bitcoinkernel

Of course, this has been to h= ave been tested on all the *nix, or
a bunch of different ISAs, though = normally it compiles quite good.
I believed it could be interesting fo= r people who wish to re-write
their own full-node or wrapped it as com= ponent for other usage in
the bitcoin stack. Doing those, without havi= ng 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
ful= l-node implementation in go, cpp or whatever another language,
maybe i= t's mature enough for them to experiment or test it as a
"monitor" con= sensus engine to check there is no differential in
block validation wi= th their current consensus engine. I'll see to
peg that standalone con= sensus 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<= br />interface, please be nice and report them accordingly.

Chee= rs,
Antoine
ots hash: a50ace52cfabade91d0fbb95f824a5f9607a251cdf8= c4d34381ea2d86725bef5

[0] https://gitlab.com/lightning-signer/va= lidating-lightning-signer/-/issues/188
[1] https://github.com/bitcoin/= bitcoin/issues/24303
[2] https://bitcoin.stackexchange.com/questions/1= 13863/in-future-will-multiple-widely-used-implementations-around-libbitcoin= kernel-be-a

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