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 @npub1mxrs...0htc 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 @npub1ej49...ndrm 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 :(

Great report on channeld using 100% CPU and getting laggy on giant nodes. Random backtrace via `gdb -ex` showed memmove in the to-gossipd queue. Ok, it's a bad implementation for big queues, which is easy to fix, but I also added a backtrace first time we surpassed 100k entries. This hit *gossipd* first: and, because it was the queue to the main daemon and I'm an idiot (writing the backtrace before setting the "done-once" flag) it recursed infinitely. But the root of *this* was a known issue, that we spam the logs when we get lots of gossip. So a log level below "debug" was added a while ago, "trace". But we had explicit logic to suppress debug messages from making the queue too long, which *wasn't* extended for trace! One line fix. Now, I went to look at the original issue: connectd flooding gossipd and slowing down. This is definitely possible, if we get a lot of gossip at startup: gossipd may have its hands full keeping up. But actually, I'm pretty sure what was happening was gossipd running slow *because* of the slow performance of its own queue to lightningd! So there's a trivial commit at the end of the series which raises the queue size before reporting an issue to 250k and explains why the other commits (which didn't touch channeld) actually fixed the issue!

FIFO Sydney for cheatcode.co.uk panel: really disappointed I couldn't do the whole thing. Hope this gave people a taste of Bitcoin developer thinking, at least!

Finally designing payer proofs, thanks for prompt @Matt Corallo! This proves that the invoice was requested by you, and paid, in a nice standard format. Fields which aren't needed are omitted, but you can still verify the signature. Was a design aim for BOLT12, but now time to bring it into the world...