In preparation for onboarding new core lighting developers are preparing a series of videos. So I've been asking ChatGPT about CLN developer features, particularly with comparison with other projects people might be familiar with. Of course, I compare myself with Linux, but it's interesting to see comparisons against other projects: **Type-safety**: OpenBSD High Bitcoin Core High Core Lightning Very high for C Nginx Low curl Moderate MySQL Moderate SQLite Moderate CLN sits near the top among major C codebases for safety discipline. **PR Submission** Core Lightning’s PR flow is unusually strict, slow-moving, and review-heavy compared to most open-source C projects — closer to Bitcoin Core or OpenBSD than to typical GitHub projects. --- Compared to “average OSS” Most projects: Feature-oriented PRs Informal review Few required reviewers Patch squashing common Tests sometimes optional Architectural discussion often post-merge CLN: Patch-first culture Pre-merge architectural scrutiny Extremely high reviewer expectations Tests are mandatory Clean, narrative commit history matters

Seriously considering putting two RTX 6000 in my upcoming build machine. Puts the price up an order of magnitude, but truly private AI might be a worthwhile investment. Never played with GPUs before, so informed thoughts welcome?

The latest (final?) #CLN release candidate fixes a long-standing bug where we could forget UTXO spends when we restart. This explains a variety of bug reports we have seen and been unable to reproduce over the years: the most recurrent being gossipd telling peers about channels which are long closed. We no longer make this mistake, but we also have to walk back and revisit old UTXOs. We do this while running, but for older nodes (like mine!) that can be a lot of blocks. In fact, and I only vaguely recall this, my node tracks back to block 500 (!) so it's going to take a while. Of course we remember progress, so you can restart slike normal during this process. Other than higher CPU consumption you shouldn't notice anything.

With my bike being repaired, I've been doing more walking. Australian cities are really optimised for driving, but I must say it gives me a lot of time to reflect on broader issues, probably a decent way to increase my nostr posting!

@Jameson Lopp recently posted on X about the danger of "store and forget" for Bitcoin over decades. Unfortunately he's right. Originally I stored my raw private keys and UTXOs (on paper, care taken) figuring that was standard. Then bitcoin core stopped supporting them! Other wallets tend only to support them for sweeping, and I wonder how long. If I were storing funds today I would use BIP39. BIP93 is cool and more general, but not widely supported, and I don't know what support will look like in a decade.

I think I got nerd sniped into implementing online compaction for CLN's gossip store. Mainly from people agitating that we should use a DB for gossip messages. This will speed startup and reduce memory usage. And it's only going to take me a couple of days' work, depending on how many side-cleanups I do. It can be hard to tell a flawed implementation of a good idea from a bad idea. But trust me, this is gonna be great!

I think finding a bug where printf("%*.s") was used instead of printf(".*s") was the point at which I realized that some C issues cannot be mitigated with better tooling...

I hate price talk, but if you're going to do it, please understand that "market cap" is a very rough *ceiling* on current value. It's neither the amount of money which has gone in, nor the amount of money which can come out. So the order of magnitude is useful to compare against other assets. But abusing it in terms of profits and losses is a category error, and I assume done mainly because it's so easy to measure. Grump over.

Jitsi Meet

Join a WebRTC video conference powered by the Jitsi Videobridge

That's in 10 minutes! View quoted note →

In two days' time Julian and I will be doing an open Jitsi meeting to discuss the work on Script Restoration. Come and ask questions! 1pm Berlin time: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2025&month=10&day=15&hour=11&min=0&sec=0&p1=5&p2=37

Should I run open hours for the script BIPs? Like, one a week for four weeks, you can show up and ask questions and I'll try to answer? That might help me get a feel for what is unclear or confusing. If so, what platform do I use? Never done anything like this before 😬

I strongly suspect that the bitcoin experience, even for veterans, will be quite different in ten years. BIP 353 brings names: ACINQ have a spec for supporting contact lists too. I expect vanity addresses to follow as providers get onboard. Silent payment addresses should replace all other on-chain addresses, especially deposit to exchanges. Though you'll probably just send to e.g. <acctname>@client.river.com (will this allow probing of account names? Will they use random ones instead? Or accept anything and if they get typo payments sort it out in customer service?) And BOLT12 provides reusable lightning addresses, which provide the off-chain analog of silent payments. Doesn't matter to you if the recipient is using some weird layer 2, either. BIP 353 returns both this and a silent payment address, so the sender wallet chooses.