Hopefully Bitcoin Core's RPC will be superceded by something different and better soon - be it a multi-reader DB or an IPC interface. But keeping everything stable while evolving the codebase is not a happy task to be doing and will create more problems in the future.

I am kind of curious if they end up going for the establishment hack, or the serial scammer.

It is cool to look at, but with a lot of it being a modern restoration the feeling inside was a bit weird. Like it made it harder to imagine what it must have been like to live within the citadel.

Seems like so many other devs were fed up with that for loop too such that my PR got no less than four ACKs and five Concept ACKs 😅

GitHub

init: Remove retry for loop by sedited · Pull Request #30968 · bitcoin/bitcoin

The for loop around the chain loading logic in init.cpp allows users of the GUI to retry once on failure with reindexing without having to manually...

That ocean mining DATUM protocol thing feels very much like not invented here syndrome.

Bitcoin Core just got its first proper useful ipc interface. If used externaly, it is more performant than querying templates through rpc, which may result in more efficient mining operations. https://github.com/bitcoin/bitcoin/pull/30510#event-14405793595

for (bool fLoaded = false; !fLoaded && !ShutdownRequested(node);) { Probably the worst piece of code remaining in the Bitcoin Core codebase. Produced two bugs this year that went into master and countless more during review cycles. And it is just there for the gui!

Ten guys jump one, what a man You fight each other, the police state wins Stab your backs when you trash our halls Trash a bank if you've got real balls

Yeah, the spam is starting to make this less fun again.

Found some new future directions to take for enabling better use cases for the kernel library. Going to be refactoring some more code over the next few weeks to make implementing them a bit easier.

The spambots are really here now.

A lot of time being spent on refactoring PRs at the moment. Not sure how I feel about that. There are so many feature PRs starving for reviews and the benefits of some of these refactors are questionable.

My first deep dive into libmultiprocess led to some pull requests and discussions on what to improve.I also contributed some high-level docs for the internal components. Now that I have an idea of the components involved, the next time I revisit it I want to focus on the serialization hooks and the thread context passing. Those still puzzle me a bit.

I need to find someone to explain the use cases behind risc0 and its potential applications for validating Bitcoin transactions and blocks. The important information is still all over the place and I am having a hard time grasping the actually important parts.

Called it, what a team! https://njump.me/nevent1qqsd0jqu03k3ez75lualc8h9akfq0ehyhexxq2tzqajy4m7ct0pvc3cppemhxue69uhkummn9ekx7mp0qgszavp6ruckc08eeyqw0afkac5w2jrrfyr8hcqc49j60372td8h70qrqsqqqqqp8dzqtx

So cmake really can't handle linking multiple static libraries together into another static library. That sucks, because the kernel library depends on a bunch of other static libraries. If we want to ship the static kernel lib, we'd now have to include all the other libs too. This is only when shipping the static lib, the dynamic lib works just fine. 😐

Ngl, the chf/usd rate is killing me.