No, but the bar is getting higher for changes.
We've certainly made more complicated changes in the past. But I'm not spending my effort for a purely academic interest: once this work is complete, if a fair assessment shows that these changes are reasonable and sufficiently powerful, I expect they will be applied.
Of course, I'm not closed to the idea that other better proposals could be made! We all win either way.
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.
nostr:nprofile1qqsfy229w70e8lgtxavlz9t78k06yrel6fxyhreteafqet8kfxhhwmg2c6av2 Jade Plus as bling at morning coffee.
nostr:nprofile1qqsfy229w70e8lgtxavlz9t78k06yrel6fxyhreteafqet8kfxhhwmg2c6av2 Jade crafternoon results. Now it's lanyard-worthy! 💚 https://video.nostr.build/cf368dd2c60eec9b7d1627a99485b7f375e3986f8100c22cdb25b72521cf68fe.mp4 
I'm stuck trying to auth. I could just paste in my nsec of course, but that's FAIL.
NIP-46 with gossip simply doesn't connect. Maybe I keep picking bad relay servers, or maybe it doesn't work at all. Maybe it's npub.cash. Maybe it's gossip. Who knows? How would I test?
Screen gives "Loading..." forever
I watched the video of nostr:npub1cev2qfuqv5s9jm5a6yvhc8ne8cdl9mh459m5g8zz759s7pw9fayqnketlq'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?
I didn't see the announce. I wonder if they're going to do NFC, for those little square tabs, or just QR codes for the screens?
I haven't been following the status of NFC, but I know people have proposed things...
I deliberately started using it about two years ago, in all fora. I think it makes me less intimidating.
yay! Thanks for the feedback!
> a) if the selector is meant to be scriptnum compatible, would be good to make that clear (ie 513 on the stack is interpreted as outputscript+collate not as 0x0102 and tested as outputamount+version.
This builds on the previous BIP, which changes this, but I agree it needs to be explicit.
> b) please use hex for the selector values...
Done.
c) you might consider two separate functions [op_tx and op_txcollate] instead of using a bit selector; makes it slightly easier to statically validate expected stack depth, though still not great.
Understandable, but since we have a bit selector anyway, I prefer this approach.
> d) not sure the ordering of collate-vs-noncollate makes sense - should "output" just always put the new data at the start of the buffer or the end of the stack do you consistently get the last output thing first?
Good catch!
I've switched the definition around to the order I think of it, i.e. txid order. But it means the definition of "output" for the non-collate case is a bit awkward: `"output" means "push a new element on the stack under the previous output elements" (i.e. the last output will be the top stack element).`
> e) input(num)witness seems like a bad idea to me, constraining how other inputs are spent just seems like asking for complexity and bugs.
I agree, so don't do that. However, it's possibly useful too, so it's allowed. Not like you're going to do this "accidentally".
> f) having a way to pull info from other inputs' annex (and your own) would be a win though, but maybe that should be an op_annex getter.
I was tempted to use separate bits for WITNESS_STACK, WITNESS_TAPSCRIPT and WITNESS_ANNEX for this reason, but the entire witness is more robust against future SegWit output types: I don't have to worry too hard about how to interpret those fields.
Note that getting the ANNEX is awkard, due to lack of DROPN. See the very-unfleshed-out OP_MULTI which would make this tenable.
> g) personally I don't think upgradability is a win here, better to upgrade by defining a new opcode than have weird semantics that people will forget to check.
Perhaps, but this argument seems very weak. Who will forget to check? The only possibility is someone who allows arbitrary selection_vectors in their script, and they're already kinda messed up.
> h) the ctv comparison at the end is inaccurate - ctv also commits to scriptSigs.
Oh, good catch! Fixed.
> i) automatically hashing it as you go rather than pushing the whole thing to the stack then hashing it seems worth considering
That seems like a regression to me. People have been proposing combo opcodes precisely because they haven't a decent costing model.
1. OP_SHA256 is a single opcode.
2. You can also now easily append/prepend/insert data that you want to commit to.
3. You have 4MB of stack, which is hard to exhaust (you can, using metadata, but it's difficult).
4. Hashing directly would reduce the cost from 12 varops per byte to 10, and you get 5200 varops (!) for every tx byte.
To reflect the depth of my gratitute for your feedback, I shall now review your lisp approach. Seems the least I can do! 💜
Satoshi originally created fully programmable money: a little programming language attached to each coin! But it was buggy and had to be disabled :(
We've pushed what's left as about as far as it can go, but rebuilding it (without the bugs!) is a lot of work. Still, someone had to try, right?
As to what it can do, there are a lot of technical answers. But the real answer is: *whatever people dream of in the future*. When we design a new computer chip, most of the software it will run *doesn't exist yet*, so we simply build it as powerful and flexible as we can.
This is the promise of programmable money: you can control your coins without requiring my approval, or even my understanding. And I want that in the world!
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
https://github.com/bitcoin/bips/compare/master...rustyrussell:bips:guilt/varops
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.
nostr:npub1e0z776cpe0gllgktjk54fuzv8pdfxmq6smsmh8xd7t8s7n474n9smk0txy 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
OP_DUP OP_SIZE 64 OP_SUB OP_LEFT:
# Enforce any "you must set this" flags.
# 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 "
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!
No. The increasing ease of borrowing pushes the price up, leading to a belief that it's up only, leading to more borrowing, then when the crash comes the knife is extra sharp from all those forced liquidations?
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.