Last Notes
Claude is really happy to write more code. This can be a super-power! But it can also mean repetition, nasty workarounds, and unreviewable code :(
For the BOLT12 payer proofs, I asked it to take my implementation, produce test vectors then compare against Vincenzo's LDK implementation. There was a bug in the spec around field ordering which this found, and it proceeded to fix my code, adding another complex pass to reorder the fields. Instead I asked it to change the Rust code, and indeed it was much simpler there too.
If I hadn't caught this, we would and been stuck with a very weird spec and a lot of gratuitous code in every codebase.
So now I need to start emphasizing the joy of simplicity, I guess.
There's a lot of repetitive work which needs to be done, and I'm happy to outsource that.
To be clear, you're thinking of deriving a second (hardened) key, for which a signature is checked in tapscript, assuming that the keypath spends will eventually get disabled? To do that we need a BIP32 path standard, and get this advice into BIP-0341 instead of the current advice on unspendable script path selection, then get wallets to implement it.
Things which actually use tapscripts need to decide whether they need to do this (is the loss of keypath spend fatal, or merely inconvenient?). This also needs a clear warning: that you should anticipate loss of the keyspend path...
I've been through tech hype cycles before. They always have a grain of truth in them (otherwise they're trivially refuted) but they don't always work out. I have been through three VR waves, for example.
I can't tell where Quantum Computing will land, though it has all the signs of needing a few more decades of occasional hype cycles.
But I *can* tell that all the proposed mitigating signature schemes for Bitcoin suck hard: they're technically impressive because they're 10x better than I expected, but they're still 10x worse than what we have now.
This means two things: I applaud and support the continuing research. And I won't support a soft fork any new cryptographic schemes until the someone demonstrates an extant QC that can factor faster than a classical one.
Americans trying to get back to the moon and missed.
This one doesn't keep getting disconnected from LND and Eclair, because we disabled the padding feature which made all messages the same length on the wire which was to be a release feature 😔
It was an obscure part of the spec, but LND have already fixed theirs for v21: kudos! I submitted PRs to Eclair and Phoenix (the latter mainly Claude, but it's a trivial change).
I still have hope for a workaround, but we'll see if I can get it before Sangbida as Release Captain says No!
#nevent1q…ykgl
Hmm. There are several things which could be done.
Firstly, the key for the inv request doesn't need to be the node key. You can use an ephemeral one, so that's one possibility (ofc your node has to honor it, but that's an implementation detail).
Alternately, fields 250-1000 are not covered by the signature. This would allow an extension to say "put an amount, signed by Bob, in field 255". Of course, clients would need to understand that that should use this amount field, not the normal one.
Also, having a mechanism to pull funds gives me the "credit card vibes" ick, but maybe that's just me...
Wow, that's some lunch with the mayor!
"Also Bitcoin Core, but in blue"
Send $$ NOW for my new project!
No, it's all agentic payments!
I'm hearing them, not listening to them :)
And I've been hearing about the premise of "regulatory clarity" and various TradFi acceptance for over 5 years. Today it's Clarity Act and Morgan Stanley's ETF. Before it was ETFs and accounting rules, etc.
I keep hearing about all the billions left on the sidelines, which will come rushing into Bitcoin when some legislative or regulatory event occurs.
Here's some history:
- Bitcoin futures ETFs. October 2021, price $61k
- Bitcoin spot ETFs. January 2024, price $42k
- March 2026, price $70k
Now, maybe it's still coming, but at this point you might want to start doubting this narrative.
Hmm, stuck in "processing".
Actually, I'm not sure how. cashu.me doesn't seem to give me an option.
I see my node made a 5000 sat bolt12 outgoing psyment about 6 hours ago though...
Done. A bit rough, but functional.
Now I serve a web page at that URL. Probably presents too much info. @nprofile…xnfk might have suggestions for what I should put here?
#nevent1q…eekl
Yes, its pure API, no website. I should probably put some info there...
Try:
https://cashu.centurymetadata.org/v1/info
Fired up a cashu mint today: should exercise my CLN node a bit more!
https://cashu.centurymetadata.org
I made enchiladas, where N = 8.
Token bucket filter for the win: most occasional posters are not *regular*.
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.
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/
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
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.
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?).
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
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!
Kick the can down the road? I cannot see the appeal from any direction...
You are minmaxing again.
Enjoy the scenery and sense of wonder!
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.
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.
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.
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).
But not relaying them disadvantages small and anonymous miners, driving centralization and thus putting my own UTXOs in danger.
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.
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?
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?
And does this mean you're okay with transactions that transfer NFTs? Because that's a financial transaction?
OTS transactions only exist to put non-financial data in the Bitcoin blockchain. Is that ok?
OpenTimestamps transactions aren't financial data, nor memes. So are they spam?
Great, enjoy. Wasn't talking or thinking about BIP110, but you do you.
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?)
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.
But but but they didn't "read the room"!!!!!
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.
None of those celebrating her departure are Bitcoiners. Because clearly they neither understand or like Bitcoin.
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.