bitjson / bch-loops Goto Github PK

(yes, I have a new account as github blocked my old one).

At this point the 'Motivation' chapter has this text;

Loops were originally excluded from this design on the mistaken
assumption that they risk consuming excessive validation
resources. In reality, a small number of VM operations make up
the majority of resource usage during transaction validation,
and any implementation of bounded loops can be many orders
of magnitude faster than the most pathological VM bytecode
constructions.

This makes people believe that the actual loops are the thing that was the worry. Naturally that makes no sense, jumping a number of times is indeed cheap, and that was never the problem.
The reason loops were disabled was the fact that it makes calling those really heavy resource-usage type of operations much much cheaper.

The logic simply is that if you have an operation that has cost Y to it, and then you surround it with a bunch of opcodes to be able to repeatedly do that same operation, you worry about the n * Y cost. Not the overhead of looping, but the fact that it became cheap to multiply cost Y.

It probably makes sense to be honest about this in the motivation and look at what kind of mitigation the original Satoshi stack had and compare that with what you present.

The spec states that begin/until are using a stack. And this makes them recursive. You can have a loop in a loop.

This doesn't vibe with the Repeated Bytes concept as described as that is stated to be a VM-global variable.

I would drop the idea of adding a global state to the VM and simply make the UNTIL opcode do the math of the amount of bytes moved (until-pos minus begin-pos).

While this is unfair in case of skipped blocks, its pretty darn cheap to do.

Motivation assumes we need loops, but the concept of CHIPs is that the status-quo is what we have today. Any divergence should be backed up with actual rationale's and preferably usecases.

So the motivation needs to be improved a lot in order to actually show what can not be done today (or may be too expensive) but could be possible with this new feature. Because from the CHIP process this is a new feature since it is not available in BCH today.

ps. the merkle-proof code doesn't seem to take under consideration that the unlocking transaction is the one that picks the depth. And as more tx go in a block, the depth will change.

Under OP_UNTIL you write:

if this control value is not an integer, error.

This is confusing as the push to the control stack is described as "pushes the current instruction pointer index to the control stack".

The proposal freely mixes "integer" and "instruction pointer" for this concept and I feel that the 'integer' is an implementation detail that should not be described in the spec. The spec doesn't care if its an actual pointer or some integer offset or something.

Please consider dropping the term 'integer' in the context of the Condition Stack and simply using the term "instruction pointer". Maybe with a single note saying that this likely is best implemented as an offset-integer.