<unnamed>

Public Key

npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s

Profile Code

nprofile1qqs0zuj4s6jq9sr2ajqc69rc53d25rwpd3afcjrfm97r2qek69hcuscpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpz3mhxue69uhkummnw3ezummcw3ezuer9wcq3jamnwvaz7tmnvakzuun4wd6xxmmjwqhxxmmd9esh2qguwaehxw309aex2mrp0yhx6at5d9h8jampd3kx2apwvdhk6qgswaehxw309ahx7um5wgh8w6twv5yhe0e7

Publishing to

nostr.bitcoiner.social

nostr.oxtr.dev

sgl.rustcorp.com.au

relay.mutinywallet.com

nostr.wine

Last Notes

2026-03-14 22:20:41 UTC

- reply

Token bucket filter for the win: most occasional posters are not *regular*.

2026-03-14 22:17:39 UTC

Finally read BIP-54 (mirror at https://bips.dev/54/) and it is straightforward,minimal and thorough. At this point I can endorse it as a good idea and worth doing.
There's no rush, but I am looking forward to activation.

2026-03-14 05:08:09 UTC

I am loving listening to the Pieter Wuille interview. It's clear from motivation to technical explanation, and Stephan shepherds the discussion masterfully!
https://stephanlivera.com/episode/730/

2026-03-11 22:11:40 UTC

- reply

Here are two of my favorites:
Vaults, where your coins can only be spent with a delay, so if you see your coins move and it wasn't you, you can force them to emergency backup address instead.
Lightning and other layer 2 protocols get simpler and more efficient. In the case of Ark, it sheds some cases where you need to trust the provider.
These ideas came up long after the script stuff was disabled. There are certainly more

2026-03-11 22:00:13 UTC

https://json5.org/
I *want* JSON5 to take over the world because it allows trailing commas.
But I have to accept that most people are just excited because it sounds like a boy band.

2026-03-11 21:12:44 UTC

- reply

Each Bitcoin you send has a "script" which says how it can be spent: usually just a signature for the owner's key. There's lots of other stuff yo can do though.
Back in 2010, Satoshi ripped out a pile of Bitcoin script because it had no limits and you could make coin spends which would blow up nodes.
Putting reasonable limits in means we can put all those back, so you can make your Bitcoin do fancy tricks, if you want (need?).

2026-03-11 00:50:24 UTC

https://github.com/bitcoin/bips/pull/2118
Finally, the PR to assign BIP numbers to the first two BIPs of the "script restoration quartet". Here's the corresponding bitcoin-dev the mailing list post:
Hi all,
I've submitted a PR to the BIPs repo to merge the first two drafts of the previously posted[1] "A Bitcoin Scripting Proposal BIP Quartet":
https://github.com/bitcoin/bips/pull/2118
The only substantive change since the last discussion is that the costs have increased for some operations (hashing and copying bytes), as a result of benchmarking on a wider array of machines[2]. This follows our conservative approach to make the worst-case validation times no worse than they are presently, on any viable hardware.
The remaining two BIPs (OP_TX, and new opcodes) are not submitted: they are mainly useful to provide a roadmap what functional gaps remain after the script extensions, and do not have full implementations.
Cheers!
Rusty & Julian.
[1] https://groups.google.com/g/bitcoindev/c/GisTcPb8Jco/m/8znWcWwKAQAJ
[2] https://github.com/jmoik/varopsData

2026-03-11 00:27:59 UTC

Randomness ("luck") is such a factor in life, and hard to disentangle.
These days I prefer to think of my own successes as 90% luck, and others' successes as 10%. Truth may be somewhere in the middle, but this formula keeps me from being an asshole!

2026-03-08 23:29:23 UTC

- reply

Kick the can down the road? I cannot see the appeal from any direction...

2026-03-08 23:24:51 UTC

- reply

You are minmaxing again.
Enjoy the scenery and sense of wonder!

2026-03-08 01:00:17 UTC

https://rusty-lightning.medium.com/the-three-economic-eras-of-bitcoin-d43bf0cf058a
This is still the best piece I ever wrote on Bitcoin. It occasionally gets referenced somewhere, and I reread it.

2026-02-28 23:05:37 UTC

- reply

You don't understand. There are no rulers. You cannot prevent people doing stupid things. This is fundamental, and hardest to emotionally grasp.
You can, however, use existing incentives to minimize the damage to the system. That's why OP_RETURN is standard: people used to embed data in outputs, which have to be stored forever and be available for fast lookup. OP_RETURN is straight harm prevention. Luke used the coinbase input to embed prayers, which has the same effect, but you have to be a miner.
The only strong incentive is fees. That's unvarnished capitalism, which has the benefit of being *simple* and *distributed*, but it's not *fair*. Assholes with more money than me are a real problem! But not one we know how to solve in a decentralized system.

2026-02-28 11:49:35 UTC

- reply

To check the signature, you hash the transaction. So the only cost that OP_RETURN is doing is the cost to download and hash it.
If it's data in the annex you don't even need fi hash it, just download it.

2026-02-28 05:07:21 UTC

- reply

You only have to download and hash: you don't have to check extra signatures (our most expensive operation) or put them in the UTXO set (our most constrained memory resource).

2026-02-28 05:00:45 UTC

- reply

But not relaying them disadvantages small and anonymous miners, driving centralization and thus putting my own UTXOs in danger.

2026-02-27 22:42:56 UTC

You will not be at peace until you understand the truth: every non-coinbase bitcoin transaction which does not eventually send funds to me is spam.

2026-02-27 22:13:47 UTC

- reply

So, OP_RETURN is fine, as is annex data which don't increase validation burden? And cutting off OP_RETURN and driving those uses to fake pubkeys, which does increase future validation costs, is a threat?

2026-02-26 21:21:52 UTC

- reply

It adds an entire transaction! Every time it does that, it uses up farmore space than an 80-byte OP_RETURN.
So your conclusion is that it's not spam if it looks like a normal transaction to you?

2026-02-26 21:14:21 UTC

- reply

And does this mean you're okay with transactions that transfer NFTs? Because that's a financial transaction?

2026-02-26 21:06:11 UTC

- reply

OTS transactions only exist to put non-financial data in the Bitcoin blockchain. Is that ok?

2026-02-26 21:02:56 UTC

- reply

OpenTimestamps transactions aren't financial data, nor memes. So are they spam?

2026-02-25 21:49:11 UTC

- reply

Great, enjoy. Wasn't talking or thinking about BIP110, but you do you.

2026-02-25 21:00:00 UTC

- reply

Indeed. Lightning commitment transactions stash the commitment number in the nSequence and nLocktime. Is that spam?
OpenTimestamps uses full transactions to timestamp data, is that spam?
Samurai (IIRC) had a method of obscured payment addresses which required an initial seed tx. Was that spam?
You can encode data in the key used when you use a taproot script spend path. Is that spam? (Can you tell?)

2026-02-23 21:33:04 UTC

- reply

I thought someone would build a great UI on top of iptables.
But my main predictive failures have been in assumptions I didn't know I was making. I thought the internet would remain basically peer-to-peer, not client-server by default.

2026-02-22 07:17:29 UTC

- reply

But but but they didn't "read the room"!!!!!

2026-02-17 22:27:17 UTC

https://www.theregister.com/2026/02/16/semantic_ablation_ai_writing/
"Semantic ablation" is a great phrase to express the reversion-to-mean effect you get when you put your writing through an LLM.
I tried it once with a heartfelt speech I wrote asking it to "increase emotional impact", and the result was... soulless. I literally only took one word that it used.

2026-02-06 23:08:12 UTC

- reply

None of those celebrating her departure are Bitcoiners. Because clearly they neither understand or like Bitcoin.

2026-02-06 22:36:50 UTC

Reading comments on Gloria's departure from people who have never contributed anything is stepping in an enraging sticky fecal mess.
The only appropriate response: keep building, keep unashamedly celebrating those who do.

2026-02-05 01:34:39 UTC

- reply

Suggesting such things means you're clearly not a Real Bitcoiner!

2026-02-05 01:33:35 UTC

Reading X, I have learned that the biggest threat to bitcoin is AI Epstein Quantum attacks.

2026-01-31 22:49:52 UTC

My brain keeps conflating "Ghislaine" with "Gharlane of Eddore", the bad guy from the 50s sci-fi pulp Lensman series.
No insight gained, sorry.

2026-01-30 09:02:19 UTC

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

2026-01-29 21:01:31 UTC

- reply

https://nostr.download/98b17a8e0b35750354e38270da480e3c35555466e150576aba14a89cf3108950.jpg

2026-01-22 00:50:55 UTC

- reply

Yep. Flat out.
https://nostr.download/d8156a3738fe46b411099eed09318d5245b9cb4870ffc1eb8e7407379144b292.jpg

2026-01-21 07:26:17 UTC

Little-known fact: just like Gloria, "Solana" is also my duress word!

2026-01-18 21:33:17 UTC

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?

2026-01-16 21:41:25 UTC

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.
❤️

2026-01-14 21:37:28 UTC

- reply

You can easily spot payments flowing through the network, just based on TCP packet size.

2026-01-14 21:30:06 UTC

Hacked up a "constant message size" change for CLN, inspired by https://github.com/lightning/bolts/pull/1304
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"!

2026-01-13 21:09:34 UTC

- reply

Strange. I work on Lightning, but somehow the sats haven't crept out of my node and weaseled into my brain to take over my identity.
Perhaps I'm too old!

2026-01-13 12:01:22 UTC

- reply

Define "bitcoiner" and I'll let you :)

2026-01-13 12:00:40 UTC

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

2026-01-12 21:09:10 UTC

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

2026-01-07 21:53:36 UTC

- reply

Except that hotel gym in the US, where I had to convert everything from lbs to figure out whether I was slacking off or just jet lagged!

2026-01-02 21:21:02 UTC

- reply

Extreme on both counts.
We're talking about people who are difficult and unpleasant to deal with, not assault.
And we're also talking about genuine significant contributions, like Linux or Bitcoin, not tasks on the edge of being automated.

2026-01-01 21:10:15 UTC

https://rusty.ozlabs.org/2011/05/19/if-you-didnt-run-code-written-by-assholes-your-machine-wouldnt-boot.html
I wrote this over 15 years ago, and it still rings true: separate the art from the artist.
It's a key stabilizing principle for me when navigating Bitcoin developers.

2025-12-29 04:34:17 UTC

- reply

Seems similar! Mine is for my specific setup: I have different machines on home vs work, so I wanted it to Just Work. And it's one file:
#! /bin/sh -e
REMOTES="workserver:22 homeserver:22 bouncehost:2222"
# Figure out likely remotes by looking for ssh ControlPath vars, as
# per this cantrip in ssh_config:
# # Reuse ssh tunnels if possible.
# Host *
# ControlMaster auto
# ControlPath ~/.cache/ssh-%r@%h:%p
# ControlPersist 10m
find_remote()
{
for r in $REMOTES; do
if [ -S ~/.cache/ssh-`whoami`@$r ]; then
echo $r
return
fi
done
# Nothing cached, try ping.
for r in $REMOTES; do
host=$(echo $r | cut -d: -f1)
if ping -c 1 $host > /dev/null 2>&1; then
echo $r
return
fi
done
echo "No reachable remote" >&2
exit 1
}
# Make sure we're in a git dir!
[ -d .git ] || (echo "Not a git dir!"; exit 1)
PWD=$(pwd -P)
REMOTE=$(find_remote)
echo "rcargo: remote $REMOTE"
HOST=$(echo $REMOTE | cut -d: -f1)
PORT=$(echo $REMOTE | cut -d: -f2)
# Make sure directory exists
ssh "$HOST" -p $PORT "mkdir -p '$PWD'"
# Sync source (exclude junk)
rsync -az --delete \
-e "ssh -p $PORT" \
--exclude .git \
--exclude target \
"$PWD/" "$HOST:$PWD/"
ssh $HOST -p $PORT ". ~/.profile && cd '$PWD' && cargo $*"
rsync -az --delete \
-e "ssh -p $PORT" \
"$HOST:$PWD/target/" "$PWD/target/"

2025-12-29 01:17:10 UTC

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!

2025-12-26 21:48:00 UTC

- reply

"and see" - > "in C".
Voice dictation good, not prefect, and I missed this on re-reading!

2025-12-26 04:31:57 UTC

https://crates.io/crates/linestats
Second Rust crate, re-implementing a utility I had written several times and see. This one takes a more thorough approach and handles corner cases a bit better. I also added percentile support which is actually quite cute.
Basically, if you have a pile of text lines, which contains some numbers, something like you've run a benchmark 20 times, produced a pile of output, line stats will gather similar lines and show you the stats on the numbers.

2025-12-25 22:49:35 UTC

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.

2025-12-25 07:35:14 UTC

- reply

WMD is also interesting for *when it was written*: the US had just gone off the gold standard so there was interest in such a cautionary tale.

2025-12-25 02:22:44 UTC

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.

2025-12-23 10:03:39 UTC

- reply

Hmm, I did a histogram mode, but it sucked if one value dominated. Percentiles a good idea though!

2025-12-22 21:15:48 UTC

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!

2025-12-21 04:43:24 UTC

- reply

Yes, it's a technical distinction, not an ethical one.

2025-12-20 03:42:51 UTC

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.
https://docs.rs/syncless/

2025-12-19 22:27:50 UTC

- reply

You're perfectly good.

2025-12-19 21:08:33 UTC

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.

2025-12-16 21:33:51 UTC

- reply

I love this pattern: excellent advice. I asked ChatGPT how to do this in Rust, and it suggested a template using a phantom type was idiomatic Rust:
pub struct ReadOnly;
pub struct Writable;
pub struct Store<Mode> {
file: File,
_mode: PhantomData<Mode>,
}
Then implement write() only in the writable specialization.
I've deferred this change for now, but congratulations: you are responsible for my first refactoring (once the implementation is complete!) 🧡

2025-12-16 21:27:10 UTC

- reply

Leaning into the type system is one of the distinctive traits of my C code, too (and something which I really miss in Python, with its tacked-on type annotations). But Rust certainly lends itself well to this style!

2025-12-15 05:19:47 UTC

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!!

2025-12-12 23:52:23 UTC

"Bitcoin is taking over the world"?
Tether is many things, but it's not Bitcoin.
https://nostr.download/799ecbaa088fc3dc36c2546add7478418779fd99b40b7ea49fdc63b66117d595.jpg

2025-12-10 02:10:18 UTC

Happy VPN-day Australia, to those kids who celebrate!

2025-12-06 21:57:15 UTC

- reply

Keep being genuine. You might not win, but you'll have a much better time! ❤️

2025-12-06 21:27:10 UTC

- reply

Good coffee can be expensive!

2025-12-05 09:11:28 UTC

Damn, right before I closed my laptop for the afternoon I had uncovered a weird bug, which git bisect says is triggered by a trivial commit.
But I really should record myself tracking it down, for my Intro to CLN Development series, so I am having to resist the urge to look at it tonight...

2025-12-04 21:02:08 UTC

- reply

First ones (very general) up at https://rusty.ozlabs.org
They're kinda boring, given it's just me and an editor window, but they lay the groundwork.

2025-12-02 22:48:51 UTC

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

2025-11-30 09:02:51 UTC

- reply

This is a good point: I shall test "local-able" models remotely first!

2025-11-30 08:56:06 UTC

- reply

Yes, we later made a lower limit config:
/* "Lightning Charge Powers Developers & Blockstream Store" */
.when_lightning_became_cool = 504500,
But I think extremely early CLN didn't do this, and my node is very, very old (continuously upgraded!). I'd have to check git history to give exact details though...

2025-11-30 07:25:36 UTC

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?

2025-11-30 07:15:16 UTC

- reply

BROKEN: Full KYC.

2025-11-29 22:11:41 UTC

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.

2025-11-26 02:25:53 UTC

- reply

Actually in Unley, but very Torrens vibes. Minus the odor...

2025-11-25 23:38:21 UTC

https://nostr.download/4e7093622238912393bba22e9440c0de523eee99da3f5774ea198defe9277778.jpg

2025-11-25 23:36:14 UTC

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!

2025-11-25 23:15:10 UTC

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.

2025-11-23 20:43:07 UTC

Cobra Kai is way better than it should be.

2025-11-19 20:59:39 UTC

- reply

You mean a Digital Asset Treasury company? 🤣

2025-11-18 21:12:46 UTC

- reply

Bitcoin core no longer supports raw private keys, which is the simplest representation I can think of.
Didn't see that coming. Maybe you're smarter than me.

2025-11-18 21:11:15 UTC

- reply

Yes. Though you have to *start* with BIP39: you can't take a secret and ask "give me this as BIP39". You can with BIP93.
The (multiple!) word lists are sub-optimal, the hashing is awkward and the checksum is so weak it makes me sad.
But I ❤️ the 12 words. It's magic UX, which makes my primate brain happy.

2025-11-18 21:02:23 UTC

- reply

It took me a while to realize that for most people, flying to a different country doesn't take half a day...

2025-11-16 20:53:12 UTC

@nprofile…xxx2 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.

2025-11-16 20:44:30 UTC

- reply

We support sqlite3 as well!

2025-11-15 23:05:13 UTC

- reply

Seems like it would only be a win if you ensure low IDs are the popular ones. And then, consider a bitmap?

2025-11-14 22:18:08 UTC

Christian Decker made a side comment on my PR about a potential further optimization for Postgres. I spent an hour on it, trying to get it to fit in our db API.
Since my wife was out with friends last night, so I dived into the implementation in earnest after the kids in bed.
Man, this is a horrible API which forces you to understand the design and history of PostgreSQL.
Until v14, the async API only supports one request at a time. (Surprise!!) You must explicitly turn on pipelining. Then you get one or more responses per request, with NULL between them. This is because you can have multiple SQL statements per string, or other modes which split responses like this (?).
You can no longer use non-pipelining APIs, once you turn this on.
You can't use PQsendQuery in pipeline mode. You need to use the lower level PQsendQueryParams with NULL params. This is documented as literally "You can't use this in pipeline mode" without explanation (the docs otherwise imply it's just a convenient wrapper). This is why you should always check your error returns!
And your code will still block forever. You need to explicitly flush the pipeline, otherwise it's cached locally. There are multiple different APIs to do this, and I'm not sure which to use yet.
Also, if you get an error in a SQL query, you need to drain the pipeline, turn pipeline mode off and on again.
Finally, the documentation warns that you are in danger of deadlock unless you turn on non-blocking mode. This makes some sense: the server won't read more commands if you're not reading, but I would prefer it to buffer somewhere.
This whole API seems to be implemented by and for people who have deep familiarity with PostgreSQL internals.
Hope the latency gain for CLN is worth it!

2025-11-08 06:45:14 UTC

- reply

Yep! You create a blinded path via a known node (or, if you want, more than one). You can put as many (fake) hops in those paths as you want.

2025-11-03 06:03:53 UTC

- reply

Ah, might be only debug builds... Sorry, I've been away from my laptop and answering on mobile.

2025-11-02 02:21:19 UTC

- reply

As an old coder, these numbers make me sad.
And I wonder what that channeld is doing? You can attach a debugger and `p tal_dump() ` and it will spew a memory tree dump out to its stderr. Might take a few seconds.
Let me look at my node...

2025-11-01 22:56:39 UTC

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!

2025-10-29 21:21:54 UTC

The last CLN release was terrible for really large nodes: the bookkeeper migrations were exponentially slow on Postgres, then the first call to bookkeeper would grind the node and even OOM it.
Some quickbfixes went in, and there will probably be another point release with those. Thanks to those who donated their giant accounting dbs!
But the exciting thing is all the optimization and cleanup work that came from me profiling how we handle this large data. Not just reducing the time (those single linked lists being abused!) which I've been spending the last weeks on, but last night I started measuring *latency* while we're under stress.
1. Anyone can spray us with requests: the initial problem was caused by bookkeeper querying a few hundred thousand invoices.
2. A plugin can spew almost infinite logs.
2. xpay intercepts every command in case xpay-handle-pay is set, so it can intercept "pay" commands.
Fixes:
1. Yield after 100 JSON commands in a row: we had logic for autoclean, but that was 250ms, not count based. We now do both.
2. Fix our I/O loop to rotate through fds and deferred tasks, so yield is fair.
3. Yielding on plugin reply RPC too, which definitely helps.
4. Hooks can now specify an array of filter strings: for the command hook, these are the commands you're interested in.
As a result, my hand-written sleep1/lightning-cli help test spikes at 44ms, not 110 seconds!
My next steps are to use synthetic data (say, 10M records to allow for future growth) and formalize latency measurements into our CI.
Next release looking amazing!

2025-10-27 21:10:07 UTC

- reply

Well, it's not obvious to me, even if that's true. You will probably receive it twice (once to discover you don't want it, then once again when it's in a block anyway?) but you won't send it (except maybe with the block again?). I don't know the details of tx and block relay. And I'm not sure what fraction of txs these filters apply to, either.
This is why I was interested in the claim of empirical results, but maybe nobody has actually measured, which is sad.

2025-10-26 20:36:14 UTC

- reply

Oh, I love empirical data! How much less?

2025-10-26 11:09:46 UTC

- reply

Not the compile times!

2025-10-26 11:09:17 UTC

- reply

GCC does compile-time checks too, but they're both valid, and both print a string of the given width, but %*.s is weird and should probably elicit a warning. The man page suggests this will print padding (* specifies the minimum width, . specifies zero precision, so no chars from string are printed) and that the string need not be nul terminated, but it printed something and valgrind complained (string was *not* nul terminated), so I suspect the man page or implementation are wrong.
But it's really a "did you mean %*." warning because I expect no code deliberately does this...

2025-10-26 10:53:28 UTC

- reply

"So, if I run knots my node won't get spam?"
"Oh, no, you'll still have it."

2025-10-25 23:22:41 UTC

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

2025-10-25 12:12:54 UTC

- reply

Yes, this is a single commit! Should have mentioned...

2025-10-24 21:55:58 UTC

I had way too much fun optimizating CLN due to a Boltz report recently. Like most engineers, I love optimizing, but bitter experience means I only allow myself to do so when I have an actual problem to solve.
My favourites:
1. Adding 1M entries to a sqlite3 table with two indexes: 81 seconds. Adding entries *then* creating indices: 17 seconds.
2. Optimization of O(n²) cleanup code by realizing it could be deleted entirely.
I admit I continued to optimize long after their performance problem was fixed, but you gotta have *some* fun!