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

I watched the video of @aj's Bitcoin-Lisp-Script talk (https://brink.dev/blog/2024/12/19/eng-call-aj-towns-bll/). 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?

OK, hot off the keyboard! Here are my first pass series of 4 BIPS: 1. Varops Budget For Script Runtime Constraint 2. Restoration of disabled script functionality (Tapscript v2) 3. OP_TX 4. New Opcodes for Taproot v2

GitHub

Comparing bitcoin:master...rustyrussell:guilt/varops · bitcoin/bips

Bitcoin Improvement Proposals. Contribute to bitcoin/bips development by creating an account on GitHub.

I took this week off to work on these, so I can post them to the ML and we can start proper discussion. But I figured I might as well share early drafts here! Especially since I am sometimes so "in the weeds" that I forget what questions normal developers might have, looking at all these words...

First day of my "week off". Caught up with a friend for the morning, started serious BIP writing in the afternoon. I'm trying to get something I can finally post to the mailing list, since that's been a source of complaints on GSR. Might not happen this week, but I'm hopeful! Also trying to do something relaxing each morning: in theory this slows things down, but in practice it's useful reflection time.

@niftynei() 🇺🇸💸🧡 recently mentioned that sighash flags are neater than raw script opcodes to achieve the same thing. I want to gently disagree: I think of sighhash flags as a shortcut, which ideally would *expand* into script. Something like (untested!): # Split flags word(s) off from signature, leaving <flags-and-sig> <flags> on stack OP_DUP OP_SIZE 64 OP_SUB OP_LEFT: <flags-and-sig> <flags> # Enforce any "you must set this" flags. <compulsory_flags> OP_DUP OP_AND OP_EQUALVERIFY # Extract those parts of the tx onto the stack, append the flags, and hash them. OP_DUP OP_TX OP_SWAP OP_CAT OP_SHA256 # Now cut the flags word(s) off the signature copy, leaving "<txhash> <sig>" on the stack OP_SWAP OP_SIZE 64 OP_SUB OP_RIGHT # Check the signature. OP_CHECKSIGFROMSTACK OP_VERIFY You can actually see how OP_SPLIT would help us here, but also you can see exactly how much work OP_CHECKSIG does under the covers!

I have a half-baked post on CTV, which it might be past time to polish and publish. But hell, I've got enough in my life without the intense online reaction I can expect from this.

It is, as far as I can tell, impossible to tell the difference between "making an inane comment on your post to be supportive" and "llm bot spamming". If I don't learn anything from what you're saying, why say it? Perhaps I need a client which doesn't show comments more than two hops away in my social graph? Probably too quiet though; I would need many more friends.

After several years of FOMO, I finally attended HRF's #OsloFreedomForum. I took a friend who's political but not Bitcoiner, so I had the experience of seeing it through someone else's eyes, as well as my own. Obviously there's a lot to unpack: talking face-to-face with activists who are working in real danger is confronting in itself, and hearing their experiences fresh and recent is an emotional and impactful experience. I was surprised, however, at the large number of Bitcoiners at the conference: it's not a Bitcoin conference, but the HRF (particularly @gladstein) has been courting bitcoiners for technical assistance (and, presumably, donations) for several years now and it has resulted in a fascinating intersection. Those present are builders, not (just?) talkers. My non-bitcoiner friend noted the remarkable humility of those present: an insightful comment. Of all the discussions I had, the one which haunts me most is a conversation with Peter McCormack (ex- WBD, now rejuvinating his home town and trying to raise awareness of UK's pressing misgovernance issues). To paraphrase: "Where are the Bitcoiners improving the world? Wasn't that what this was about?". In a context of three days' exposure to people who are dedicating their lives to something much bigger than software, this question really affected me. I was expecting to leave the conference with a list of software priorities, and I did. But I still feel it's inadaquate, and so I'm now pondering the question: "what else should I be doing?".

I'm going to publish more on nostr. I need to settle on a desktop client though: mobile is always optimized for consumption and adds speed bumps to actual creation. I'm also going to need to run my own instance so that I can archive all my random thoughts and not lose them in the ether. I've made that mistake many times since I stopped publishing everything on my own blog...

I'm finally going to Oslo Freedom Forum this year. I'm going to listen, not speak. But TIL @calle is going to be there, so I finally get to fanboy^H^H^H^Hmeet him!

Sadly, "poof of reserves" is probably the next big thing in exchanges. Still.

When it comes to Bitcoin technical discussions, the phrase "Greg Maxwell was right" is almost tautological.

I restarted my "Shit Bitcoiners Say" Twixter account. I could have done in on nostr, but it's pure noise and I prefer to keep my Nostr bubble high signal as long as I can. As a side note: Reading the "For you" feed for that account is pure sewer-wading. Hard to do that and still be funny, not just snarky and horrified!

@jack mallers hasn't Tweeted yet, by reports that he's heading a new Pile of #Bitcoin venture are an interesting move. We shall, of course, refer to the new company as "Tether One".