CHIP 2024-12 OP_EVAL: Function Evaluation

[bitjson]

Copying snippet from Brainstorming OP_EVAL - #10 by bitjson :

OP_EVAL vs. word definition

@cculianu

Another approach is to break this up into 2 things: […] OP_DECLARESUB […] OP_CALLSUB […]

[…]

Disadvantages:

• Less efficient for one-offs, OP_EVAL style executions… since you need to both declare the subroutine and then call it, increasing byte count.
• More stateful VM since we introduce this abstraction of “known subroutine table” which now needs to be tracked…

Yes! I definitely need to include a section comparing the OP_EVAL CHIP with “proper” Forth-like word definition (also called OP_DEFINE/OP_UNDEFINE/OP_INVOKE in old Libauth branches).

As you pointed out, a full “word definition” upgrade proposal is quite a bit more involved: how and where we track definitions, any necessary limits for those new data structures, whether or not a word can be undefined (we only have OP_0 to OP_16 + maybe OP_1NEGATE!), what makes a valid identifier (only numbers? any single byte? multi-byte?), should we include Forth OP_FETCH/OP_STORE corollaries for data (some discussion of OP_EVAL vs. a TX-wide “data annex” here), and probably many more details.

Fortunately, we have a great argument for avoiding this bikeshed altogether: we can easily prove that OP_EVAL is the optimal construction for single-use evaluations (as you mentioned). Even if a “word definition” upgrade were hammered out and activated in the future, OP_EVAL would still be the most efficient option for many constructions. (This coincidentally was the same argument that made P2SH32 a strong proposal vs. OP_EVAL – even with OP_EVAL, P2SH32 remains the more byte-efficient construction for those use cases.)

As BCH VM bytecode is a concatenative language, a perfectly-optimizing compiler is quite likely to produce single-use evaluations from common pieces of different words/functions, even if the contract author didn’t deliberately design something requiring OP_EVAL (e.g. MAST-like constructions).

So:

• OP_EVAL is feature-equivalent to word definition (each enables all the same use cases)
• OP_EVAL typically requires 1 extra byte per invocation, but sometimes saves 1 byte vs. OP_INVOKE.
  • OP_EVAL is 3 bytes (<index> OP_PICK OP_EVAL) for many calls, but some will be optimized to only 1 byte (just OP_EVAL)
  • OP_INVOKE is always 2 bytes (<identifer> OP_INVOKE).
• OP_EVAL always saves 1 byte per definition by avoiding the OP_DEFINE.
• OP_EVAL remains optimal for some uses even if a future upgrade added word definition (as a 1-byte optimization for some function calls).

[cculianu]

Jason, I don’t disagree with going OP_EVAL and ignoring OP_EXEC but I am having trouble agreeing with this claim:

@bitjson

Stack isolation here adds no security

I don’t think this is true. One can imagine a scenario where it adds security – if you exec “untrusted” code, the stack isolation, etc, provides perfect security. The untrusted code cannot muck with any state you are tracking at all. All it can do is receive parameters and return 1 or more result(s).

This adds security.

Thus, I think the statement “OP_EXEC stack isolation adds no security” is a false statement. It does add security, demonstrably.

Whether or not that security is of any value to imagined use-cases is another matter. But security it does add, even if the added security is value-less, inconsequential, useless, etc (TBD).

It’s like saying: “Passing-out and sleeping inside a locked, bulletproof tank versus on a park bench adds no security… because I don’t anticipate ever being robbed.”

No, the tank is more secure than you sprawled on a park bench. Whether or not that security makes any difference to you is another matter… but demonstrably one is more secure than the other, even if the additional provided security leads to identical outcomes as the less secure situation in practice…

[bitcoincashautist]

@cculianu

One can imagine a scenario where it adds security

Here’s an example:

{some trusted code} OP_2DUP <untrusted_code> <2> <1> OP_EXEC OP_VERIFY {some trusted code}

If the sequence between 2 blocks of trusted code passes, from point-of-view of outer code it will just be a NOP which can’t affect stack state around it. If it fails, the whole script fails.

With OP_EVAL you can’t allow the untrusted code in any place because it could mess up the stack and break the code around it, so it could only be ran as last operation in the whole script, and some VERIFY opcode must precede it: {some trusted code ending with OP_VERIFY} <untrusted_code> OP_EVAL

[cculianu]

Yep, decent example.

@bitjson Just to be clear – I’m all in favor of simple OP_EVAL! I am not advocating for OP_EXEC! I am perfectly happy with OP_EVAL. I am not a contract author and I have no idea what authors need. To me, the usecase of a compiler optimizing common code into OP_EVAL bits makes tons of sense… even for that reason alone it’s fine by me.

[tom]

This whole discussion has gotten weird.

People are comparing two ideas that neither is perfect. Notice that here on bchr we don’t actually have the actual proposals in detail so the “it uses less bytes” is a bit hard to follow and likely closes the discussion to a lot of readers.

But there is no point in comparing two, we can make 20 new proposals based on what it is that we actually want. There is no reason to limit us to just those two.

And, as I pointed out in another thread: Brainstorming OP_EVAL - #14 by tom, the comparison is mostly based on false premises. There are not just TWO ways of doing things that pick things like stack protection. Stack protection is an ingredient that can be applied to either propoosal under discussion today.

The real question is not about picking between two options, the real question is to find a good way that uses the various ingredients we actually want.

As far as I can tell, the ingredients you can mix and match are:

• Stack-protection
• Requiring a method declaration and then calling it based on a method-index (two opcodes).
• Being able to put methods in another output on the same transaction.
• Being able to get the method-code from stack, which implies being able to execute code that is untrusted.
• Being able to write self-modifying code.

Personally, I’d add stack protection as that is virtually free. It stops script writers doing really nasty things that breaks good programming assumtions.

Having the idea of a method declaration is neat as that saves bytes in calling, as your indexes are always 1 byte. Additionally it provides compiler safety because your compiler can ensure that the method you call has the right number of parameters (see linked post).

Being able to put methods in another output fits very nicely in the rest of our scripting design and allows neat things like being able to do verification of the methods-holding-output by simply hashing it and comparing the hash, all in script.

Being able to call code that at any point is stored on the stack, however, sounds to me like something you really really want to avoid. I mean, we introduced p2sh-32, so maybe it is not sane to introduce a no-checking way to execute a script that can be pushed in the unlocking script. Now, I know you can also check the hash of that, but if you’re supposed to always include that check, then that warrents its own opcode. An op-mast, if you will.
The problem with executing code that was not known at the time of mining the locking script is that this is money that can be unlocked by people coming up with a script to unlock it. That may be neat, but it doesn’t make for good money.

Using the stack to store your code you eval means you can write self-modifying code. This likewise has no place in modern programming strategies. Absolutely double that when it comes to money.

Last reason why storing your code on-stack makes no sense is that stack operations are defined to cost a price to operate on. This will be activated in May. As such either the usage of eval will cost double (once for pushing, once for executing it), or it needs some sort of exception. Which makes the design no longer coherent as a whole.

Further OP_EVAL critisisms;

• the chip as it is on github right now writes: “the evaluation may modify the stack and alternate stack without limitation”.
  This means you could dirty things like writing a method that does 5 pops.
  This idea goes against 60 years of computer science concept and learning, and I don’t like it. It gives the contract writer not just a gun to shoot its own foot, it likely will leave a crater.

• " ii. The OP_CODESEPARATOR operation records the index of the current instruction pointer (A.K.A. pc ) within the OP_EVAL -ed bytecode."
  I read that as a way to skip all code from the jumped-to-position to the first codeseparator and start evaluating there.
  This will be useful if you want to write self-modifying code. Which is not something that belongs in money.

I don’t like op-eval. It makes hacky code writing the norm, it provides lots of ways to do extremely dirty things which will make the The Fourth Annual Obfuscated Perl Contest Results - The Perl Journal, Fall 1999 look like easy to understand code.

[bitjson]

OP_EXEC misunderstands contract security and usage

I’ll have to mention OP_EXEC in the CHIP’s evaluation of alternatives, and I don’t want there to be any doubt that the rationale treats it fairly.

I’ve tried my best to steelman OP_EXEC, but as of now, my analysis is:

• OP_EXEC misunderstands contract security and usage. It only seems to make sense if you haven’t tried to use it.
• OP_EXEC has zero advantages and significant disadvantages vs. OP_EVAL.

If anyone disagrees, it should be easy to provide a counterexample: a contract with an exploit that OP_EXEC could prevent.

The reasoning trap

WARNING: experienced programmers will almost certainly be misled about OP_EVAL and OP_EXEC by their intuitions from other languages/environments.

This is downstream of 1) our unusual environment – the whole transaction is the potentially-abusive input, not just the hypothetical “code” being consumed by OP_EVAL/OP_EXEC (and in another sense, the VM is itself a “sandbox”: malicious code can’t consume excessive resources or take control of the node), and 2) the concatenative programming paradigm. (It’s a deep rabbit hole, see Thinking Forth and maybe 1% the code.)

(@cculianu and @bitcoincashautist please forgive me for nit-picking parts of your posts to explain myself now, I appreciate you guys commenting here. )

@cculianu

One can imagine a scenario where it adds security – if you exec “untrusted” code, the stack isolation, etc, provides perfect security. The untrusted code cannot muck with any state you are tracking at all. All it can do is receive parameters and return 1 or more result(s).

This is the reasoning trap: we’re used to the concept of “untrusted code” elsewhere, so we assume that VM bytecode has a direct analogy. Skip some steps, and stack isolation looks like a solution to some plausible contract security problem – no need for further review.

I’m arguing that 100% of these imagined scenarios actually rely on internal contradictions which can be revealed by fleshing out the example.

1. Stack “isolation” is superfluous – any contract where it seems to prevent an exploit has other equivalent exploits not prevented by the isolation.
2. You can already get that “stack isolation” behavior – for zero bytes – today, simply by fixing your code (or, more likely, using a good compiler). If you think you need OP_EXEC to get that effect, your contract is wasting bytes. In fact, a linter could automatically optimize contracts by removing instances of OP_EXEC (replacing them with OP_EVAL and/or compiling them away altogether).

I hope to convince everyone to either:

1. Try it yourself and prove me wrong by offering a single counterexample, or
2. acknowledge that stack isolation is an anti-feature, not some imagined security-for-efficiency tradeoff.

“Untrusted” means nothing without context

@bitcoincashautist

Here’s an example:

{some trusted code} OP_2DUP <untrusted_code> <2> <1> OP_EXEC OP_VERIFY {some trusted code}

If the sequence between 2 blocks of trusted code passes, from point-of-view of outer code it will just be a NOP which can’t affect stack state around it. If it fails, the whole script fails.

(Again, thanks for your comments here @bitcoincashautist. I get that you already prefer OP_EVAL and you’re just trying to objectively review OP_EXEC; please forgive me for nit-picking your comment. )

This code snippet includes OP_EXEC, but it’s missing all the context we need to review. In fact, you even mention that the whole OP_EXEC portion is unnecessary in your description: “from point-of-view of outer code it will just be a NOP”.

Please correct me if you meant to say something else – doesn’t this sentence imply that the computation’s result can simply be pushed as data instead of using OP_EXEC?

My claim about OP_EXEC

“Stack isolation” is a reasoning trap. If you think it might add security value, your mental model is omitting critical context.

If stack isolation offers any security value at all, it should be easy for someone to refute this with a single example. No hand-waving away the context though: that’s where the logical errors are hiding.

For anyone who still cares to defend “stack isolation” as an idea:

• Can you fill in your “trusted code” and “untrusted code” blanks with a concrete example? Who is using this contract?
• What potential exploits can be performed by the untrusted code – who loses money and how?

TL;DR

OP_EXEC is like requiring motorcycle helmets in a swimming pool. Given the context, “safer” is not a word that comes to mind.

[bitjson]

Word/function signature verification

I see some discussion about function signatures being generally useful in programming (I agree), and that being somehow an argument for OP_EXEC and/or “stack isolation”.

Please note that Libauth and Bitauth IDE have supported compile-time verification of “function signatures” and behavior since 2020 – I’ve found it invaluable for optimizing various constructions (e.g. P2SH assurance contract - #15 by bitjson predates CashTokens lock-in).

Adding – via a consensus upgrade – some half-baked runtime checks to approximate function signatures wouldn’t simplify or improve our current capabilities.

[bitjson]

If I understand correctly, @andrewstone designed Nexa’s OP_EXEC.

@andrewstone, do you disagree with my review of OP_EXEC? I also responded to you here:

https://x.com/bitjson/status/1880227699198714348

GAndrewStone: TBH, tl;dr. It allows the template to execute untrusted holder constraints.

OP_EXEC is like requiring motorcycle helmets in a swimming pool.

It simply misunderstands contract development.

Even with the correction I described (@NexaMoney’s version is even more nonsensical) – OP_EXEC adds no security and harms protocol complexity, contract complexity, and overall transaction sizes when compared to OP_EVAL.

If you disagree, it should be easy to provide a counterexample that doesn’t hand-wave about context (e.g. leaving a blank for the “untrusted code”). Given any particular contract, what exploit is prevented by OP_EXEC’s stack isolation? Please be sure to include threat model info, then I can help you optimize it by switching to OP_EVAL.

---

Again, unless someone can produce a credible counterexample (with enough context to review), I don’t plan to spend more time on OP_EXEC.

[tom]

Thanks Jason for a very enlightening series of posts.

You asked a bunch of times to show a “counterexample”, which was your choice of words indicating an example that did something nasty. Inside of the VM. Knowing full well that a VM is already a sand-box.
Repeating that so often while ignoring all the actually quotable objections I made is really quite enlightening.

You’re arguing that stack isolation is “not good” and that “experienced programmers will be misled” by “intuition”. Yeah, because who would have the audacity to ask people with experience! Where is the fun in that?

Ok, lets leave the schoolyard and sum up the actual facts;

• op-exec from nexa is super expensive in every usage. Nobody likes that one.
• op-eval avoids a function signature and avoid stack safety to be less expensive.
• a simple op-exec1 (lets use my design for discussion sake) is not expensive. Is actually cheaper than op-eval for repeated cases. And Jason stated he expects hundreds or more calls in some cases. Arguing cost makes op-eval lose.
• a simple op-exec1 design with pushing of a single int for argument count allows stack safety.

A argument count as part of a function description has 2 main advantages:

1. a toolset like an IDE can do compile time checking. Notice that “compile time” is per definition at the time of transaction construction. I mean, no full node compiles, so this one should have been obvious. But we got someone misunderstanding this, so lets be clear. A transaction with a single output that has a bunch of pre-defined subroutines can be used by a contract you’re building. You’ll compile the contract using the binary library and voila, you have compile time safety.
   Or, in short, this 1 byte that indicates the number of arguments is the simplest form of an API-docs for your IDE to use. Pretty cheap, if you ask me!

2. a much more important usage of an argument count is the stack protection.
   Now, this is not about being able to escape your VM. That suggestion is more like a “when did you stop hitting your wife” question.
   Instread, this is about avoiding all the hallmarks of unsafe code.

Arguing “it is not worth anything” is a great way of saying you don’t actually have an argument against it, you just don’t like it. Fine, don’t like it. It still is valuable to others and practically free.

Unsafe code in this context is about unpredictable code. If I use this library method in my contract, will it do funny stuff? Will my money be stolen because I didn’t manage to understand the code I used from another dev?

Being able to chop up a script on-stack, partly execute it with usage of codeseparators and indeed altering or reading the stack outside your subroutine, those are all really nasty things that makes code very hard to understand and near impossible to test to be “correct” when used in not yet written scripts.

But the bottom line here is that this is money. This is not some toy virtual machine to do cool new things with. Well, not new, nothing here is novel. Jason may think he came up with this all on his own, but sorry to say that he’s about 60 years late to that party. One way or another any and all options we pick have been tried before.
Maybe that knowledge helps letting the ego’s deflate and we can get back to picking something that actually is good for Bitcoin Cash.

I started the discussion some time ago here:

@tom

The real question is not about picking between two options, the real question is to find a good way that uses the various ingredients we actually want.

As far as I can tell, the ingredients you can mix and match are:

• Stack-protection
• Requiring a method declaration and then calling it based on a method-index (two opcodes).
• Being able to put methods in another output on the same transaction.
• Being able to get the method-code from stack, which implies being able to execute code that is untrusted.
• Being able to write self-modifying code.

Personally, I’d add stack protection as that is virtually free. It stops script writers doing really nasty things that breaks good programming assumptions.

My opinions on each item above in the original post.

And, to repeat, op-eval doesn’t just allow spaghetti code that can steal your funds, it ALSO has a pretty serious security issue by default:
code can come from any place without being known at the time of building the transaction. That allows injection of untrusted code and that means bugs can steal your money.

You can claim you can write code to verify your inputs, but first of all this after DECADES is still the number one issue in software: unverified inputs. (xkcd).
And that just throws out of the window the entire argument that it would somehow be cheaper byte-wise, being forced to write your own input verification.

None of the arguments hold water, which is why Jason isn’t replying to my posts, which is why he uses very angry and dismissive language (tit for tat) because he knows he’s in the wrong and his lovely op-eval is rotten under the surface.

[bitcoincashautist]

@tom

It still is valuable to others

Which others, how many smart contracts have you designed? Let’s hear from these others.

@tom

his lovely op-eval is rotten under the surface.

It’s not even his (it came from Gavin, remember?) and it is certainly not rotten, it is the preferred solution.

[bitjson]

@tom

None of the arguments hold water, which is why Jason isn’t replying to my posts

@tom again, unless someone can produce a credible counterexample (with enough context to review), I don’t plan to spend more time reviewing stack isolation.

@bitcoincashautist

It’s not even his (it came from Gavin, remember?)

And I’d go back further than that! There are many decades of prior art here – if anything, this CHIP is taken more from Chuck Moore than Gavin or any of the other 2012 proposals. OP_EVAL gets BCH VM bytecode to a “fully capable” Forth dialect.

On the other hand, the various 2012 proposals did nonsensical things like clearing stacks and preventing “nesting” – i.e. functions calling functions – and generally misunderstood the control stack and/or how non-trivial Forth programs are factored. (Understandable for the time: VM limits were a huge, untenable problem that overshadowed clear thinking about a lot of topics, and most “smart contract” ideas were very hypothetical. We’re spoiled now to have more certainty on both.)

[bitcoincashautist]

@bitjson

In fact, you even mention that the whole OP_EXEC portion is unnecessary in your description: “ from point-of-view of outer code it will just be a NOP ”.

Please correct me if you meant to say something else – doesn’t this sentence imply that the computation’s result can simply be pushed as data instead of using OP_EXEC?

It will be a NOP only if it passess, else it will fail the TX, that’s just like some:
<0> OP_UTXOBYTECODE <0> OP_OUTPUTBYTECODE OP_EQUALVERIFY sequence. The individual locktime/sequence opcodes work the same. If it passes it’s like a NOP from PoV of surrounding code, otherwise it fails the TX because predicate not satisfied.
You can’t replace that with data because result depends on TX context, and the purpose is to force spender to set the TX context right.

OP_EXEC makes it possible for untrusted parties to insert their predicate checks into the placeholder inside the main contract, without the possibility of breaking “outer” predicate checks created by the designer.

Consider running OP_EXEC with arguments 0 and 0 (which means the untrusted_code can’t affect the main stack): it can only be some kind of user-specified -VERIFY sequence.

{some trusted code} <untrusted_code> <0> <0> OP_EXEC {some trusted code}

Now imagine the preceding trusted code does some calculation, and the succeeding code is supposed to continue it. The latter code can trust the stack state that the former code resulted in, because the OP_EXEC guarantees that it couldn’t have changed it.

but if you have {some trusted code} <untrusted_code> OP_EVAL {some trusted code} then the untrusted_code could’ve changed the result of the preceding block, and the succeeding block would have to treat the stack state as untrusted data - just as if it’s being executed after input’s data pushes - the spender could’ve provided anything to be run as untrusted_code.

EVAL could also be used to create a slot in the contract for user-set predicate check, but then it must be either called as either first or last in the contract (and if last then the main must execute a final VERIFY to “lock-in” whatever checks it did).

Here’s a full example (link to open it in BitauthIDE).

Unlocking script:

// Next user-set constraint commitment, decided by the spender of this TX
<0x4ae81572f06e1b88fd5ced7a1a000945432e83e1551e6f721ee9c00b8cc33260>
// Reveal user-commited constraint for this spend
// (the one committed by the previous TX)
<0x51>

Locking script:

// Example of some fixed covenant code
OP_INPUTINDEX OP_UTXOVALUE OP_2 OP_DIV
OP_INPUTINDEX OP_OUTPUTVALUE OP_EQUALVERIFY

// Force inheriting the fixed covenant part, while allowing the user
// to change only the commitment for the user-set constraint
OP_ACTIVEBYTECODE <33> OP_SPLIT OP_DROP
OP_ROT OP_CAT
<0x8862> OP_CAT
OP_HASH256 <0x87> OP_CAT <0xaa20> OP_SWAP OP_CAT
OP_INPUTINDEX OP_OUTPUTBYTECODE
OP_EQUALVERIFY

// Verify additional constraints committed by the previous TX
OP_DUP
OP_SHA256
OP_PUSHBYTES_32
// Current user-set constraint commitment
0x4ae81572f06e1b88fd5ced7a1a000945432e83e1551e6f721ee9c00b8cc33260
OP_EQUALVERIFY
OP_EVAL

[tom]

@bitjson

@tom again, unless someone can produce a credible counterexample (with enough context to review), I don’t plan to spend more time reviewing stack isolation.

And ignoring all the actual relevant points against your chip that have been made.

But, really, you’re barking up the wrong tree. You are the one making a suggestion that goes againts decades of actual software engineering practices.
You are violently against a practically free way of avoiding said problems.
And said barking is without any arguments. The wider bitcoin cash ecosystem doesn’t need you to “review” anything. This specific feature is not hard to do. If you refuse to even address actual critisism of your proposal, then please go away. We don’t need that. We need someone that actually can work with others. More people working together get better results.

At this point NOT accepting that there is a one byte-costing approach which avoids well documented and known problems is just plain malicious.

Again, you have given NO arguments why you don’t want this one feature in the list of possible features for the common idea of subroutines. While not even mentioning, let alone discussing, any other features that would be pretty cool to have.

[bitcoincashautist]

@tom

And said barking is without any arguments

You’d know, considering you’re doing all the barking with no arguments.

[tom]

I would be very interested in hearing if contract coders see value in features like:

• having a subroutine that is able to alter the stack in a way that goes against the basic “function” based design of cashscript. Or any programming language using function design.
  Specifically, a subroutine would be able to remove more from the stack than “expected” by the function signature. Which means you can’t expect it to behave the same even if you call it with the exact same arguments.

• the ability to have the unlocking script have a push which is your unlocking code. Not like p2sh where the hash has to match, but without hash verification. A transaction mined on-chain that you can write code to unlock.

• the ability to cut / join and otherwise alter a subroutine’s code.

Anyone interested in any of those features? Is the risk of making mistakes worth it to you?

[bitcoincashautist]

@tom

having a subroutine that is able to alter the stack in a way that goes against the basic “function” based design of cashscript

Script is not CashScript. Script is more akin to assembly, which is why EVAL is fine.

@tom

Specifically, a subroutine would be able to remove more from the stack than “expected” by the function signature.

If you wrote a function in CashScript that takes in 2 args and returns 1 then the compiler would create a well-behaved Script bytecode for that function - which doesn’t even try to break out by consuming more than 2 stack items, so why would we need low-level guarantees when we’re already controlling the bytecode to be eval’d and can ourselves guarantee that it adheres to calling convention or have the compiler produce compliant bytecode?

A function written in CashScript can’t surprise the compiler because compiler is the one creating the bytecode - compiler decides what’s the max. number of stack items it will pop during execution.

If the contract author wants to make his program modular, to occasionally “load” some of his code to be executed from input’s data or from another input/output, he always needs to authenticate the code against a commitment (dup, hash, equalverify) - even when using OP_EXEC - which is why Jason makes a good argument that OP_EXEC doesn’t really add security, it only adds some flexibility for one class of use-cases that would be akin to 3rd party plugins, but we don’t see much use for those.

[emergent_reasons]

Heavy debate on merits and details is very important. Attacks on character, ad hominem, passive aggression, caricaturing others, etc. are not warranted or welcome here. Fair warning.

[bitcoincashautist]

I pasted the whole HTML of this page to Claude and asked him to find examples of:

@emergent_reasons

Attacks on character, ad hominem, passive aggression, caricaturing others, etc.

Here are the receipts, for posteriority:

Looking through the thread, here are some examples of unconstructive behavior:

From Post #23 (Tom):

• Accuses Jason of deliberately ignoring points: “Repeating that so often while ignoring all the actually quotable objections I made is really quite enlightening.”
• Sarcastic/dismissive: “Yeah, because who would have the audacity to ask people with experience! Where is the fun in that?”
• Personal attack suggesting malicious intent: “he knows he’s in the wrong and his lovely op-eval is rotten under the surface”
• Questions motives: “Jason may think he came up with this all on his own, but sorry to say that he’s about 60 years late to that party”

From Post #27 (Tom):

• Hostile/dismissive: “If you refuse to even address actual critisism of your proposal, then please go away”
• Accuses of malicious intent: “is just plain malicious”

From Post #28 (bitcoincashautist to Tom):

• Retaliatory snark: “You’d know, considering you’re doing all the barking with no arguments.”

In Post #31, a moderator (emergent_reasons) had to step in and warn: “Heavy debate on merits and details is very important. Attacks on character, ad hominem, passive aggression, caricaturing others, etc. are not warranted or welcome here. Fair warning.”

The exchange appears to have devolved from technical discussion into personal attacks, particularly from Post #23 onward.

[emergent_reasons]

Can just paste the whole html. We are living in the future

Ok back to OP_EVAL.

[Jonas]

I’ve been thinking about this for a while and I certainly don’t think stack protection should be implemented for OP_EVAL.
Messing with the stack is a feature that could open the door for many compile time optimizations.
A contrived example could be a reusable bytecode to clean up the stack:

<push bytecode to pop everything recursively from the stack>
<some more pushes>
[...]
OP_DEPTH
OP_IF
  // Do some stuff, leave "true" on stack to exit
  OP_IF
    <index to stack clean bytecode> OP_PICK OP_EVAL
  OP_ENDIF
OP_ENDIF
OP_DEPTH
OP_IF
  // Do some more stuff, leave "true" on stack to exit
  OP_IF
    <index to stack clean bytecode> OP_PICK OP_EVAL
  OP_ENDIF
OP_ENDIF
[...]