Writing release notes is fun, but the part I really like in the release process is preparing the first commits for the *next* release: 1. BOLT spec updates. We check all the BOLT quotes in our source, and have a script to update the spec version one commit at a time. This is a grab bag of typo fixes, feature merges (which may mean we no longer need our local patches), and occasionally major changes. It's unpredictable enough that I enjoy it 2. Removing long-deprecated features. We now give a year, then you can enable each deprecated feature individually with a configuration flag, then (if we haven't heard complaints!) we finally remove it. This means removing code (usually ugly shim code) and is a genuine joy. I've started this for 25.02, and it's a balm after the release grind...

The problem with CTV is fees. When you look at most designs using CTV, they need *another* tx, and an anchor output, so they can pay fees. What they really want is "this tx, plus an input and optional change output". People tend to ignore fees in their protocol design. But I'm implementation they're critical, and only getting more so. Lightning has been down this path!

Trying to do everything, but mainly doing a little of everything badly. #CLN release is late, I've been ignoring the BOLTs changes,, I haven't even looked at GSR since my OP_NEXT talk, and my comprehensive list of opcodes for introspection is still stuck in my head. I try to take time to post on #nostr over morning coffee though, since doing that every day helps move things forward.

To recycle an old joke: "Bitcoiners' self-worth reaches 90k." The price is like the weather. People can discuss it endlessly, but unless you're going out into it, it's trivia. Don't be the price. It's boring.

After a long day going through all 44 issues and pull requests for the milestone, and lots of hard work, I've got it down to 49. This could take a while...

44 tasks on the milestone to go, 44 tasks on the milestone, If I spend all day rewriting your code, There'll still be 44 tasks on the milestone. Feeling grumpy. Looks like release will be late. Grrr....

GitHub

ElementsProject/lightning

Core Lightning — Lightning Network implementation focusing on spec compliance and performance - ElementsProject/lightning

Here are the very draft interpreter and BIPs for Script Restoration. I'm seeking comments (looking at @Rijndael and @stevenroose here!) on all aspects, including format and what opcodes make sense to combine into a single proposal. There are definitely some tweaks we could make to costing (it bugs me that the formula for OP_MUL is not symmetric, for example!), but that part is pretty solid. Once we have a single proposal that we think is well-specified, reasonable and useful, it'll be time to get coauthors (I have a day job, and it's not this!) and formally propose it for broader scrutiny.

GitHub

Script Restoration First Draft by rustyrussell · Pull Request #1 · rustyrussell/bips

This is a first-draft PR so we can gather comments, review and feedback!

And interpreter (not other parts, so not actually usable except bench and test!):

GitHub

Varops draft implementation by rustyrussell · Pull Request #1 · rustyrussell/bitcoin

PR seems a good way to gather feedback comments! See the equivalent PR for the BIP: rustyrussell/bips#1

Really nice, thoughtful panel at OP_NEXT with @Peter Todd and Jay Beddict. Good questions from Pete Rizzo, felt like we could have gone much, much, longer...

Woke at 6am thinking about Bitcoin. Couldn't get back to sleep, so I finished first pass of my budget estimation util. You give it a script, if gives you a maximum budget it could use, or a maximum input element size it could handle. It's approximate (doesn't actually evaluate properly), but it's an upper bound. I need to come up with some good examples though...

Almost finished my xpay series: its had a series of epic side quests! In particular, yesterday, adding the idea of "biases" to layers, so you can favor/disfavor particular channels for routing. This is easy: the hard part is deciding how to scale it for real use. I ended up deciding on a scale from -100 (avoid) to +100 (awesome) with useful values generally being 1 to 10. This is actually an exponential factor underneath, with +/-100 making the score 30x better or worse, which is more than enough to override everything else. Last step is layer persistence: you want to keep that information you learned across restarts. In addition, I'm release captain for this release, *and* I have to clean up my Script Restoration code for my OP_NEXT presentation next weekend (and write my talk). I anticipate the 24.11 CLN release may be delayed :(

My problem with "stable channels" is not technical, but entirely around incentives. "A banker is someone who lends you an umbrella when it's sunny and asks for it back when it starts raining". People want downside protection. But you cannot keep enough reserves to give it to them in Bitcoin, you need some other asset like USD, which is much harder to audit. So in practice you offer some limit on downside protection, hopefully well-documented! But no limit on upside protection. Of course if you hit the downside limit your (broke) customers leave, so your business model is likely "hope Bitcoin goes up". This can be extremely profitable, of course. But high-risk ventures with this kind of "heads I win tails you lose" property rarely attract the most ethical of players :(