Add ability to analyze dynamic arguments for opcodes like ROLL

[dgpv]

Currently, if an opcode uses one of its arguments as an index on the stack, we require this argument to be static.

There are possible practical scripts that can use dynamic stack indexes, so having ability to analyze these seem to be valuable.

Here's the link to relevant discussion on delvingbitcoin: https://delvingbitcoin.org/t/bsst-plugins-for-covenant-opcodes/137/2

For convenience, I copy here parts of conversation from there:

dgpv:

Each value of for ROLL will require its own execution path. bsst could put some upper limit on , generate that many execution paths, analyze them one by one, and then show them in the report as ‘branches’ with conditions like = 1, = 2, etc.

But if could happen to be above this limit, the analysis will be incomplete. The report can show a warning, something like “argument for PICK can be above the limit, analysis is incomplete”. This warning will be shown in each execution path generated for each value of .

If there are more than one such place in the script with non-static arg for PICK or ROLL, you will get a lot of execution paths in the report :-). I guess there needs to be an upper limit for the number of exec paths, too.

ajtowns:

I was looking at OP_VAULT which pops n+5 elements off the stack, one of which is n. (In particular: I wanted to DUP one of the items deepest in the stack, and do so automatically by DUP’ing n first)

...

Being able to specify $n in [1,2,3,4,5] as a constraint in the file (ie pretending there was DUP 3 NUMEQUALVERIFY just prior to the ROLL or PICK for each value in the range) and just rerunning the analysis multiple times would work fine (and put the burden of the combinatorial explosion onto the user). I ended up just reframing my question to avoid the problem though, and that worked fine too.

[dgpv]

Being able to specify $n in [1,2,3,4,5] as a constraint in the file

Created separate issue for this: #15

[dgpv]

I've implemented the feature, it is now in https://github.com/dgpv/bsst/tree/dynamic_pick_roll branch.

It seems easy to do the same to CHECKMULTISIG with non-static number of keys and signatures, too.

But I have problem with naming the setting to select the number of samples to generate for the argument.

Right now it is this:

  --max-samples-for-dynamic-pick-or-roll=3

        Maximum number of samples to generate when non-static argument
        for OP_PICK or OP_ROLL is encountered. Each generated sample will
        get its own execution branch, and if there are more samples possible,
        the 'Unexplored' execution branch will be added, which won't be
        analyzed and will be there only to indicate that not all execution paths
        was explored

Making similar setting just for CHECKMULTISIG seems excessive, so I would prefer to have to use a shared setting for all opcodes that might need this feature.

I have problem naming such setting.

--max-samples-for-dynamic-args seems short enough, but might be confusing... like, what is "dynamic args" ? It seems meaningless without context... "dynamic args" might have meaning if we add 'pick-or-roll' context, but I can't find a fitting name for this type of args in a general context.

Any ideas ?

[dgpv]

@ajtowns as you have requested this feature, maybe you could find some time to check out how it looks, and tell if it works as you expected

[ajtowns]

--max-samples-for-dynamic-args

Perhaps something like --max-samples-for-dynamic-stack-access ?