<unnamed>

Public Key

npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s

Profile Code

nprofile1qqs0zuj4s6jq9sr2ajqc69rc53d25rwpd3afcjrfm97r2qek69hcuscpr9mhxue69uhhxemv9ee82um5vdhhyupwvdhk6tnpw5q3gamnwvaz7tmwdaehgu3wdau8gu3wv3jhvqguwaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skcqguwaehxw309aex2mrp0yhx6at5d9h8jampd3kx2apwvdhk6qgswaehxw309ahx7um5wgh8w6twv5ccwcss

Publishing to

sgl.rustcorp.com.au

nostr.oxtr.dev

nostr.bitcoiner.social

relay.mutinywallet.com

nostr.wine

Last Notes

2026-03-11 23:11:40 CET

- 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 23:00:13 CET

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 22:12:44 CET

- 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 01:50:24 CET

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 01:27:59 CET

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-09 00:29:23 CET

- reply

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

2026-03-09 00:24:51 CET

- reply

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

2026-03-08 02:00:17 CET

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 06:07:21 CET

- 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 06:00:45 CET

- reply

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

2026-02-27 23:42:56 CET

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 23:13:47 CET

- 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 22:21:52 CET

- 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 22:06:11 CET

- reply

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

2026-02-25 22:00:00 CET

- 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 22:33:04 CET

- 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-17 23:27:17 CET

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-07 00:08:12 CET

- reply

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

2026-02-06 23:36:50 CET

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 02:33:35 CET

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

2026-01-30 10:02:19 CET

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-22 01:50:55 CET

- reply

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

2026-01-21 08:26:17 CET

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

2026-01-18 22:33:17 CET

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 22:41:25 CET

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 22:37:28 CET

- reply

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

2026-01-14 22:30:06 CET

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 22:09:34 CET

- 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 13:01:22 CET

- reply

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

2026-01-12 22:09:10 CET

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-01 22:10:15 CET

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 05:34:17 CET

- 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 02:17:10 CET

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 22:48:00 CET

- reply

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

2025-12-26 05:31:57 CET

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 23:49:35 CET

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 08:35:14 CET

- 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 03:22:44 CET

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 11:03:39 CET

- reply

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

2025-12-22 22:15:48 CET

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-19 23:27:50 CET

- reply

You're perfectly good.

2025-12-19 22:08:33 CET

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 22:33:51 CET

- 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-15 06:19:47 CET

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-06 22:57:15 CET

- reply

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

2025-12-05 10:11:28 CET

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-02 23:48:51 CET

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 10:02:51 CET

- reply

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

2025-11-30 09:56:06 CET

- 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 08:25:36 CET

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 08:15:16 CET

- reply

BROKEN: Full KYC.

2025-11-29 23:11:41 CET

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 00:15:10 CET

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 21:43:07 CET

Cobra Kai is way better than it should be.

2025-11-18 22:12:46 CET

- 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 22:11:15 CET

- 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-16 21:53:12 CET

@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 21:44:30 CET

- reply

We support sqlite3 as well!

2025-11-16 00:05:13 CET

- 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 23:18:08 CET

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 07:45:14 CET

- 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 07:03:53 CET

- reply

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

2025-11-02 03:21:19 CET

- 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 23:56:39 CET

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-27 22:10:07 CET

- 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 12:09:46 CET

- reply

Not the compile times!

2025-10-26 12:09:17 CET

- 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 01:22:41 CEST

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 14:12:54 CEST

- reply

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

2025-10-13 09:58:43 CEST

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

2025-10-11 06:05:40 CEST

- reply

Your math looks out, BTW: 0.0000000763 not
0.00000000763% of the entire Bitcoin network.
You are ten times richer than you said 😱