CHIP 2021-05 Bounded Looping Operations

[MathieuG]

I want to add to the discussion that loops would make array-datastructure abstractions much more useful in high level languages compiled to BCH script

‘for each element in array do x’, currently variable sized array abstractions are not really possible.

IMO the usecases in the CHIP should be updated, different people seem to have the understanding that this functionality isn’t really required yet by contract authors in practice - i strongly disagree but the CHIP is very much lacking in this regard as the use-cases are described in a very abstract way and haven’t been updated since 2021…

@MathieuG

it would be good to document the practical needs for “Simplifying Repeated Procedures” like merkle proof validation and “Aggregation” like aggregating value of all inputs. This way we can better understand its practical relevancy.

For example the workaround for a person adding multiple UTXOs to a smart contract and the contract aggregating the input values would be a simple consolidation beforehand. We already see this type of “consolidate UTXOs” button used for the Paytaca browser extension. Only In the case where the added inputs are controlled by different parties would this not be possible.

Any practical & pressing needs for merkle validation would also be good to be documented. Merkle root validation was an important part of pmv3 tokenization but luckily that complexity was avoided by the CashTokens CHIP which replaced it.

It would also be good to refer to the native introspection CHIP to emphasize that aggregation was expected to be delivered in this way:

While it would be possible to define aggregate operations like OP_TXINPUTVALUE and OP_TXOUTPUTVALUE to make this derived state accessible to all contracts, this proposal considers standardization of any derived state to be premature

now there’s also aggregation of CashTokens in the in- and outputs so it saves having to introduce atleast 4 different opcodes

Further it would become possible to construct tx.hashOutputs and tx.hashPrevouts like we had before native introspection. This could be useful in case a multi-step contract can commit to later payouts, like demo-ed in my ‘upgraded sha gate’ contract