So, you might not have noticed, but I still haven't published my BIPs. That's mainly because I've been having too much fun with Julian who has been hacking on the benchmark code as we refine the BIP. In particular, OP_ROLL. BIP-143 already notes this opcode can be slow, and indeed, moving every stack element by one is bad enough when you can have 1000 of them. If we want to increase that to 32k, which we'd like to do so you can push every output onto the stack, for example, we can no longer ignore this problem. This is the only case where stack manipulation itself causes a significant overhead. For every other opcode we can treat it as the cost of interpreting opcode and it is not addressed by varops. Annoying! So we have benchmarks which show how much we should charge for it to limit the damage it can cause. But everything else is derived from a "bytes manipulated" model, and so I would like to extend the model a little to take into account this case. Not just for bitcoind as it is today, but for any reasonable implementation in the future.

@Blockstream Jade Plus as bling at morning coffee.

@Blockstream Jade crafternoon results. Now it's lanyard-worthy! 💚

I watched the video of @aj's Bitcoin-Lisp-Script talk (

AJ Towns on bll (Basic Bitcoin Lisp language)

AJ Towns presents on Basic Bitcoin Lisp language bll, symbll, and bllsh.

). Summary: 1. Lisp a the classic alternative to Forth for embedded use, so makes sense for Bitcoin Script. 2. Iteration is definitely a super power. 3. Definitely worthy of further research. My main concern is that it requires much more broadly-defined limits. The varops work does a very limited subset of what is needed in general, *because* we operate within a 4MB max opcode limit already. varops *only* has to extend it so that large data doesn't make things worse, and we get to ignore anything which isn't proportional to data being operated on, figuring that's already possible. An approach with iteration has to worry about more than that, requiring a general system of CPU consumption limits. That's not impossible, but I have *not* done that. For example, OP_DUP3 of three empty stack operations costs 0 varops. If you could do billions of these, this assumption that we can ignore those stack operations would be invalid. The good news is that I am tending into that area with my OP_MULTI proposal. Prior to this, nothing operates on more than 3 stack entries, so ignore the overhead of stack operations (OP_ROLL is the exception, but in practice it's really fast, and still limited to moving 998 entries). With OP_MULTI, this needs to be taken into account, and if it can cause significant time to be spent on stack operations, the varops model will have to be extended. However, OP_MULTI is still very much limited to the stack size. To be fair, I'm considering increasing that from 1000 to 32768, because it's reasonable to have almost that many outputs (P2WPKH), so I might be forced to extend the varops model to cost that appropriately. Now I need to go read AJ's Python code, since I have other questions about the exact nature of these limits (does space include overhead? 0 byte allocations are not free!). So, if you're interested in extending script, I believe you should fairly consider this. I would like it to advance to a proper BIP, of course, so we could get more of an apples-to-apples comparison, and that's a lot of work! Side note: everyone working on Bitcoin Script replacements is smarter than me. It's intimidating! 💜

npub.cash dead? I never did figure out how to get my sats from there. I guess I should figure out how to receive zaps to my lightning node. That seems terribly complex. I can't just put a bolt12 in nostr somewhere?