pkt on Nostr: ...

quoting nevent1q…xr24

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...

Our current generation of compilers and languages has a really serious limitation with regard to critical code like the Bitcoin Core consensus: you can't ask a compiler to compute the maximum possible stack size used during a function call.

This is easy for compilers to implement because the call graph is known. Obviously, in some cases such as recursive or external calls the answer is infinite, or unknown. But making it possible to compute this in advance would be a significant improvement on the status quo, where you simply have to do testing, and hope it works.