Hear me out... a Bitcoin Script interpreter written in Bitc…

Not possible by design (unless you accept exponential script sizes)

Again I wish to reiterate that the more BSV protocol devs keep saying "BSV can do everything ETH can" the more crushing the disappointment will be for creative devs like OP

I have something neat brewing though :]
The real fundamental limitation of bitcoin L1 has to do with state management, not loops/jumps etc

Haha. How much do you want to bet?

I'll bet 10 BSV, just don't show me something that grows like O(k^n) script size, or uses compute oracles to string transactions together

Can you please clarify what is `k` and `n` in the example above?

Also, can you please define 'compute oracles'? Just want to make sure we are on the same page.

I look forward to it!

Can you characterize or quantify the "limitations" as it pertains to state management?

Each day that passes, I'm realizing there are less obstacles to what I thought was impossible before.

k is something like 'number of distinct opcodes', but I'll accept k=2 as well. n is script length you are trying to evaluate. Compute oracles will be defined in a paper I'm currently writing, which btw covers your SuperAsset design as well

This will also be covered in coming paper but for now have a look at xhliu's "tokens without backtracking (almost)" and then @702's comment in this thread: https://powping.com/posts/a8323f5a627b1e26ba6d5493b6c61fdb238c0c439017ee265e4fc307d021cfb6

Another great post by xhliu, in this case imagine how you would implement the EVM's CALL op for distinct "contracts" deployed without a priori knowledge of each other: https://xiaohuiliu.medium.com/how-to-scale-ethereum-today-9bbaece3fb2e

K is bounded at most to whatever number of instructions there are (ie: a sufficient constant C)

So we can simplify in Big-O to just O(n).

All programs grow in O(n) where n is the program length.

In other words, all programs' code size by definition is length O(n).

If I take this bet, as defined, then I will win trivially.

Something's amiss.

🤔

I said k^n (simplified to 2^n), not k*n. The size of the in-script *interpreter* grows exponentially with the size of the longest script it can interpret. But I already think I jumped the gun here :x it'd be (2^k * n) for k ops which indeed is O(n)

* for N ops
I need to slow down

Anyway I'll send you 10 BSV anyway if you promise to give a thorough review/analysis of this short upcoming paper

Man proving a negative is hard and not even a good goal usually

Oh, thanks I misread that. Okay we're good there.

What is a Oracle compute?

Eval+reentry (eval arbitrary code read from PUSHTX) is what could cause exponential blowup. Maybe you could do the same static analysis we do for SCALL but I shudder to think how that would look in bitcoin script...

I think you could do it at runtime with O(n^2) by examining reentry stack

Well most languages have a stack depth limit, and in any case it would be depth^2 not n^2. But yeah it gets pretty unwieldy pretty quick.

Yeah that's totally what I was thinking of but forgot when I had to explain myself mhmm