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!

Rough thoughts on OP_EXPIRE: 1. Optimizes the unhappy path for contract timeout (you don't need another TX to timeout). Though timeout is usually unlikely, there are cases like atomic swaps where you have to charge for it to avoid griefers. 2. You want both relative and absolute. 3. Adds another reason to do mempool eviction, not just double spends, fee increases and timeouts. May be interesting to implement. 4. You want this in an address format too, in consensus, so you can create expiring addresses. Relative doesn't seem to make sense here. The last is a different use case, but currently expiry is implied and not enforceable, yet watching an address forever is not realistic. 10 years max, for a donation sp address, I would think. I'm broadly supportive, as an incremental improvement.

Cobra Kai is way better than it should be.

@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.