February 2024

Topic: Dev Weekly Status Time: February 1, 2024 01:00pm Pacific Time (US and Canada) Join Zoom Meeting https://us05web.zoom.us/j/87666370902?pwd=bEZDUlJ0MGJ5V3dVMUhVdHl5QzdFdz09 Meeting ID: 876 6637 0902 Passcode: 85U0bF

Making good progress again on node. I've stubbed in all of the "chaser" objects and implemented their initialization, destruction, and messaging. The design calls for each chaser on an independent strand, which allows them to perform long-running and expensive operations concurrently given enough threads. Each is registered to receive it's triggering event(s) via a subscriber which is retained by the full_node class, which operates on the network strand. Events are created by the other chasers. Protocols negotiate for objects (e.g. headers/txs/blocks) over the wire and submit these to chasers, which manage chain state, such as the tx pool (DAG) and header tree as well as the parallel block download queue. The submission of these objects to the appropriate chaser is the external trigger for chaser activity. Protocols also register for events, such as to broadcast a newly confirmed block/compact or accepted transaction and to download blocks that have been accepted via candidate headers messages.

Topic: Dev Weekly Status Time: February 15, 2024 01:00pm Pacific Time (US and Canada) Join Zoom Meeting https://us05web.zoom.us/j/87666370902?pwd=bEZDUlJ0MGJ5V3dVMUhVdHl5QzdFdz09 Meeting ID: 876 6637 0902 Passcode: 85U0bF

coming, zoom is updating, slowly

I've completed the concurrent header sync implementation. This adds a "chaser" to maintain state across connections, where previously we could only run one connection at a time when syncing headers. The chaser maintains a "currency window" which is set to 60 minutes. Headers older than this are cached in a std lib hash table, along with their validation chain state (which gets stored in the database with each header). When a header chain is both "strong" (more work than the database candidate chain) and "current", the headers from the hash table are moved to the store, and these and any that were not previously in the strong branch are "candidated" (ordered into the candidate chain). This is like block confirmation in the "confirmed" chain, except that the candidate chain is the strongest valid *header* chain available. This is always at least as strong as the confirmed chain and they are usually the same. I just noticed a startup on 10 peers where we went from process startup with empty store to fully-populated and validated candidate chain (831,014 headers) in 17 seconds. Anything under a minute is pretty reasonable given that we don't optimize peer connections (drop slow ones) when syncing headers, as we don't want to prioritize large/fast peers. It's been up and running for a few days with no issues, performing both the initial header sync and ongoing updates in the same logic.

This means headers are complete?

2024-02-19T21:01:54Z.1 Headers from [71.163.41.211:8333] complete at (831164).

Yeah, that’s the indication that the peer headers were exhausted.

That time was from a fresh start, so it included seed time

It’s a start :)

Topic: Dev Weekly Status Time: February 22, 2024 01:00pm Pacific Time (US and Canada) Join Zoom Meeting https://us05web.zoom.us/j/87666370902?pwd=bEZDUlJ0MGJ5V3dVMUhVdHl5QzdFdz09 Meeting ID: 876 6637 0902 Passcode: 85U0bF

Competitive headers first protocol is complete, as is competitive blocks-first. The former is the lead stage of parallel block download. The latter kicks in on (way old, can't find any) pre-headers channels (though it's not ideal to run them together, as blocks will orphan against headers).

Spent the day today refactoring the headers first and blocks first protocols and chasers to properly allow for forking below the top. Stupid, and I ended up doing what I remember doing in the || download prototyping work a few years ago. Working well though, even a bit simpler and faster.

Yesterday I took a short detour to implement the longstanding objective of chain "milestones" (avoiding another mixed metaphor, as a checkpoints and a milestones are on roads - though not "chains" mind you), as well as minimum chain work.

minimum chain work is fine as long as it's not configured by developers, but versions of bitcoind ship with preconfigured values. This could allow that configuration to reject the valid chain, resulting in a stall - a soft fork. The code doesn't determine these, it's done by developers. So this will remain configurable and should really default to top checkpoint work. In any case it's done.

@evoskuil vietnam ?!

What do you work on?

Now .. i;m working as a ciso ...

And you wanna do code reviews for Libbitcoin?

Let me return to buenos aires ... i can help you with test and automated code analysis if you want

Awesome

👍

Team meeting at 4pm NYC time today

ok

Check here for zoom link

ok perfect

Topic: Dev Weekly Status Time: February 29, 2024 01:00pm Pacific Time (US and Canada) Join Zoom Meeting https://us05web.zoom.us/j/87666370902?pwd=bEZDUlJ0MGJ5V3dVMUhVdHl5QzdFdz09 Meeting ID: 876 6637 0902 Passcode: 85U0bF