Hosted by stickies-v at CoreDev 2025-02-26 at 16:00
No transcript of the conversation.
The purpose of this demo was to showcase the py-bitcoinkernel Python libbitcoinkernel wrapper, with the specific focus on showing that this library makes it very low-barrier to explore and interact with the libbitcoinkernel interface. Specifically, on most platforms, the library can be installed from PyPI without dependencies, and basic interactions only take a few lines of code.
Hosted by glozow and stickies-v at CoreDev 2025-02-28 at 09:30
What are the goals of the review club?
Are these goals compatible? They could be: to answer newbie's questions, we also need experienced developers there to answer them.
Hosted by TheCharlatan at CoreDev 2025-02-27 15:00, transcription by stickies-v
Chainstate keeps their own CChain class for keeping track of their chain of blocks, which is basically just BlockIndex entries, and manages the UTXO set.
ChainstateManager is there to orchestrate interactions between BlockManager and Chainstate and facilitate AssumeUTXO's multiple chainstates.
Currently, only ChainstateManager is exposed in kernel API. Should we instead expose structures that allows users to implement AssumeUTXO functionality by themselves? We could expose a Chainstate and Blockmanager to facilitate that.
Hosted by ryanofsky at CoreDev 2025-02-27 11:40, transcription by stickies-v
Think of multiprocess in terms of the features it provides.
The first main feature is modularization. Having a separate binary for gui, wallet, node, that prevent lockups between processes. This also allows to e.g. spin up multiple GUIs to a single node, or a node without wallet, ...
The second feature is the -ipcbind feature. In addition to be able to spawn process, we can listen to a socket which anyone can connect to. This allows third-parties (e.g. Stratum V2 as one current practical example) to hook into Bitcoin Core internals. ipcbind was of course required for the first feature (modularization), but it just offers more flexibility on top of that.
Hosted by mzumsande at CoreDev 2025-02-27 10:20, transcription by stickies-v
There are multiple stages to validating a block:
The three steps can happen in different orders. In IBD, we first receive all the headers up to Consensus::Params::nMinimumChainWork before we ask for any blocks. Then we download up to 1024 blocks ahead of time, so we may be missing a block's predecessors. So the steps cannot be done sequentally. This is also why the IBD logs are "janky": sometimes nothing happens for a few seconds (because blocks are being downloaded), and then suddenly a lot of blocks can be connected. Downloading can be in parallel, but validation needs to be sequentially.
Hosted by glozow at CoreDev 2025-02-27 09:00, transcription by stickies-v
Discussion on p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs
TxOrphanage has 2 goals:
Date: 2024-12-08, Africa Bitcoin Conference 2024
In this workshop, we'll build a simple block data analysis tool. Rather than use the Bitcoin Core RPC interface, or parse raw block files, we'll be using the experimental, unreleased libbitcoinkernel. This workshop is aimed at more seasoned developers, please make sure to check you feel comfortable with the [[#Prerequisites]] listed below.
The libbitcoinkernel project is a new attempt at extracting Bitcoin Core's consensus engine. The kernel part of the name highlights one of the key functional differences from the deprecated libbitcoinconsensus and in fact, most libraries: it is a stateful library that can spawn threads, do caching, do I/O, and many other things that one may not normally expect from a library.