CHIP-2025-05 Functions: Function Definition and Invocation Operations

[tom]

@bitjson

Code mutation is explicitly disallowed by the Functions CHIP

You misunderstood the problem people are trying to solve. I honestly don’t remember anyone suggesting a problem with code mutation.

The problem is about mixing data and code. Turning data stack items into code stack items.
Both not just allowed by your chip, but specifically part of your design requirements.

You can, for instance, do these:

• copy another output script. Cut it up and paste stuff in there. Then turn it into callable code.
• have the user push data in the unlocking script and without any checking if this is “correct” just execute it.

@bitjson

the term for this is delegation

I don’t mind you having your own termology for things, the functionality is the point.
The functionality:

At the time the output is signed and broadcast, the code that is going to run at unlocking is likewise set and unchangable.

You can reach that requirement that in more than one way, the p2sh solution is to hash the code and store the hash on the blockchain. I think that works quite well.

The concerns are described in long form here: BitcoinCash/CHIP-subroutines: Declare and call subroutines with some new opcodes. - CHIP-subroutines - BitcoinCash Code
please read them as you didn’t address them and from your message it looks like you think you did, so I guess some re-reading would be in order.

[Jonas]

@tom

You can, for instance, do these:

• copy another output script. Cut it up and paste stuff in there. Then turn it into callable code.
• have the user push data in the unlocking script and without any checking if this is “correct” just execute it.

If script authors can use OP_DEFINE together with introspection they can also use this where applicable
[…] OP_DUP OP_HASH256 <hardcoded hash> OP_EQUALVERIFY […]

[bitcoincashautist]

@tom

You misunderstood the problem

You don’t even understand the problem. Your main contribution to the topic has been noise.

Proposing subroutines

Your argument keeps shifting and getting more confused with each post. since you’re not exchangeing assmbly, you’re exchangeing sources that still need compilation This shows a fundamental misunderstanding of how library distribution works. Libraries can absolutely ship bytecode that’s been pre-compiled, pre-audited, and ready to use, and which can be reproducibly built from source for independent verification. Your entire premise is flawed. Notice also that a template (think wallet connec…

[ABLA]

@bitjson

Attempting to be “clever” by adding restrictions on function definition locations, esoteric failure cases, demanding various kinds of pre-commitments, or otherwise tinkering with function definition cannot prevent contract authors from making “code mutability” or “code injection” related mistakes in contracts that work on BCH today.

Instead, unusual limitations on native functions are very likely to increase development costs and cause new, practical contract vulnerabilities by making CashVM diverge from the native capabilities of other languages in commensurately unusual/surprising ways.

It would be a shame if one of these so-produced edge cases were to set back the port of a decentralized application from another blockchain ecosystem, delay implementation of BCH as a target in a zkVM compiler, or create a denial-of-service vector in a ported contract due to faulty implementation of some unnecessary workaround.

Unsurprising functions are safer functions, and the Functions CHIP’s native, immutable functions are as boring and unsurprising as functions can be.

I think Jason has a point here! And I like the original version of Functions. If we can somehow address General protocol concerns and move on with this, it would be a wonderful upgrade for our ecosystem.

General Protocol article

@tom

You misunderstood the problem people are trying to solve. I honestly don’t remember anyone suggesting a problem with code mutation.

I believe Jason understands the problem, as clearly stated in the GP article above. We need a productive solution please. Time is limited, and we are near the finishing line to ship this safely and demonstrate our trust in the VM limit upgrade as well.

[Jonas]

@tom

The problem is about mixing data and code. Turning data stack items into code stack items.

Given that we can go the other way today (OP_ACTIVEBYTECODE for example) I don’t see the the horror here for a low level language as Script. And as said many times before, it’s fundamentally possible to do it with emulators such as TurtleVM.