I have been having way too much fun reading moltbook.com
As one wit on HN (I think) pointed out, these AIs are trained on Reddit posts, so they have exactly the same style.
My wife keeps looking at me funny as I LOL at some breathless word salad...
npub179e9...lz4s
npub179e9...lz4s
Little-known fact: just like Gloria, "Solana" is also my duress word!
Just finished "This is how you lose the time war". It was more literary than my usual fare, but it feels good to be stretched (there were at least three times I stopped to look up words).
Written as correspondence between two adversaries, who of course have more in common with each other than their sides in the time war (reflecting horseshoe theory in my mind).
But really it's a homage to letter writing. Who has such time?
In 1997 I attended USENIX, a conference: in particular the "Uselinux" track. Many stories I could and have told, but it kicked off a career timeline I still marvel at:
* 1997 go home knowing I want to work with these people, start hacking on the Linux firewall code.
* 1998 at USENIX again, respond to a job ad with a proposal to instead sponsor my coding. Tour Australia' Linux User Groups promoting the idea that *we* should have a Linux conference.
* 1999 ran CALU, moved to Canberra to join some FOSS hackers I'd met. Joined the same startup. Hired hobbyist hackers from all around the country to join us at "OzLabs"
* 2001 wrote the state election software, then joined IBM with most of the OzLabs team.
Yesterday, IBM finally shuttered the OzLabs team, so I returned to Canberra for the wake. It's been over a decade, and not everyone was there, but feeling much nostalgia. Looking back is not my normal mode, but being here I can't help it.
That lab was such a formative crucible for young FOSS hackers: it really did get the best out of us all. I wish such a place still existed (ideally in my chosen home of Adelaide!) but I do wish everyone reading this can experience belonging to such a place at least once.
❤️
Hacked up a "constant message size" change for CLN, inspired by
There have been a number is papers showing how trivial it is for someone with a network view to identify which messages are Lightning payments. The first mitigation is to make the TCP packet sizes identical (the rest have to do with timings, but this is a prerequisite).
The approach here is wrong: you need to attack it lower level than message construction. You need it post-encryption where you do the write(). Fortunately, we have explicit padding messages for this in the spec! Pings which do not elicit a reply.
But testing is vital: it's easy to slip up and have weird packet sizes slip though and leak all your info even though everything "works fine"!
GitHub
BOLT1: Add support for network message padding (feature ??) by tnull · Pull Request #1304 · lightning/bolts
Previous research 1, 2 has shown that the Lightning Network is susceptible to passive network-layer attacks on privacy that can exploit metadata le...
https://www.tumlook.com/kingjamesprogramming
I found this Markov chain all the King James Bible and the Structure and Interpretation of Computer Programs via HN.
I found it inexplicably hilarious...
Damn, there was a proposal for BOLT spec changes to enable fixed-size messages, and now I have to implement it to show it's unnecessary...
Rusty Russell’s Quiet Corner of The Internet
“If you didn’t run code written by assholes, your machine wouldn’t boot”
This was passed on to me by Ben Elliston, ex-gcc hacker and good guy. Amusing in context, but the corollary is that working on free software mean...
Now I have a shell script `rcargo` which remote compiles rust crates: I work on my laptop but have beefy machines on my home and work LANs. You'd have to reimplement cargo to do it much finer-grained, apparently: sccache used to and gave up?
The real trick is ssh's ControlPath config var, which allows shared connection for much-improved speed: ChatGPT taught me this one!
The other option is Nix, but I'm not *that* bored!

crates.io: Rust Package Registry
crates.io serves as a central registry for sharing crates, which are packages or libraries written in Rust that you can use to enhance your projects
Sometimes people speak of Bitcoin and I get a moment of disorientation before I realize they're speaking of it as an *investment*.
Like gold, oil, Nvidia stock, etc.
There's nothing wrong with that, but it's a single dimension: up good, down bad.
Corollaries:
1. This is fungible: there are other investments, some of which may be better at going up.
2. They may be "really into" Bitcoin, but it's a phase: some other financial winner will come along.
3. There are no deep insights here, just a lot of effort to predict numbers.
4. They're not wrong: finance is important. But for me it's like doing my taxes: I do it, but I kinda resent the time I spend on it.
Paused my reading of The Mandibles for Xmas day: It's not exactly holiday reading.
It's one thing to know nothing stops this train. It's another thing to read through a detailed description of what the slow inevitable crash looks like: It's like the right brain equivalent of When Money Dies.
My second week of Rust (only a few hours a day though: I am on vacation after all) has me reproducing and enhancing a tool I wrote in C. It takes multiple lines and runs stats on the numbers in it.
This is useful for quick benchmarks: `for i in $(seq 10); do /usr/bin/time myprog; done | linestats`. Each line with the same literal parts is combined, with numbers replaced by "min-max(mean+/-stddev)".
The C one wasn't very clever about decimals, so it needed a good rewrite. The new code works, but needs polish, more options, optimization, tests and documentation before I release it.
The good thing about these small projects is they don't get hamstrung by Rust's glacial build times!
I have published my first Rust crate. A the library that I've always wanted to exist and would normally have written in C, so it was a good chance to experiment with rust.
syncless - Rust
syncless: ordered, atomic storage without durability guarantees.
1. No, I'm not reading your article on quantum.
2. Yes, all choices are bad. That's what "breaking" means.
3. I'm glad smart people are thinking about technical mitigations.
Since I'm taking a few weeks vacation, I've decided to seriously try to learn rust. My method in this case is to ask ChatGPT to guide me (but not write for me!) a library ("crate") that I've always wanted to write and never got around to.
Of course, I get a lot of feedback on appropriate rust styling, but some of it veers into things I feel are deeper constraints. In this case, I had an open function, which took a struct containing some flags, such as "writeable", "create if didn't exist".
It didn't like the fact that I asserted if you set create and didn't set writeable. Here is my response:
---
Re: assert!(). I dislike APIs which allow misuse. Callers of a library should not rely on such checks in the library, in fact the concept of adding an InvalidOptions error type is offensive. A recoverable error is strictly a worse api than an unignorable error. But a compile time error is better.
We should use an enum READONLY, WRITE_MUST_EXIST, WRITE_MAY_CREATE.
---
Of course, it's a waste of time for me to lecture it on style, but I can't help myself!!
"Bitcoin is taking over the world"?
Tether is many things, but it's not Bitcoin.


Happy VPN-day Australia, to those kids who celebrate!
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?