Figure I'll write what I work on each day, why not?

Today, I got back to working on "askrene" for Core Lighting. The idea is to extract the core logic of the experimental "renepay" plug-in into an Oracle you can ask for routes (and provide feedback on what happened). This is much more composable: anyone can write a plugin which uses this information, *or* an alternate pathfinding plugin to replace it.

It's built around the idea of "layers" which are where information lives: you tell it what layers to use when you ask for a set of routes. This has many uses: you might have route hints or blinded paths you want (or have to!) use. You might want to constrain a payment to a particular channel for rebalancing, etc.

In theory, these layers can be exported and imported: you can share information about the state of the network between nodes. I'm sure there's a pile of obfuscation needed to preserve privacy in this case, but it's an interesting idea...

Wow, nostr is giving very "welcome to Living, now configure your modeline" 90s vibes. Lots of clients, most abandoned, very easy to "choose wrong" and not be able to do things like NIP-46. And yes, you're going to have to learn what that is :)

Nope, looks like that's a client not a server. Trying 'cargo fillmydisk' on gossip, which seems to be a popular client. Which will probably need an ssh tunnel because, y'know, web...

Except, Amethyst on Android. No NIP-7, no NIP-46. I guess most people use a web extension? Hmmm, trying nkcli, wish me luck!

Literally founded by core developers, so no surprise or conspiracy there...

I gotta write some code for that! Hard to do on mobile...

Since returning from Bitcoin++ in Austin, I've been trying to alternate between working on Lightning one week, and Bitcoin hacking on the other.

Mainly, I've been finishing my Script interpreter cpp modification so I can make more comprehensive benchmarks. I've also given in and ordered a raspberry pi 3, 4 and 5 to benchmark.

I hope to answer the key questions on what a realistic budget for large stack objects should be. In particular, there are four reasonable limits on their size (I'm not considering changing the 1000 stack element limit, since that seems roomy!)

1. 520 bytes. We are here now, but as Script gets better that will be very limiting.

2. 520,000 bytes: simply limit the total stack size, not individual entries.

3. 4,000,000 bytes. This allows you to put the largest possible transaction on the stack. But you need a total limit of at least twice this, so you can make a copy: you can't do much in script without doing this!

4. 400,000 bytes. If number 3 is too much of a reach, this means you can put any standard tx on the stack. Again, you want a total limit of at least twice this.

My laptop, with something stupid like 26MB of level 3 cache, and my build machine with 32MB, can handle this fine. But what about the Pi?

I'll find out next week...