I’ve recently had some free time and decided to implement a plugin for some covenant opcode - mainly as a way to look at how easy new complex opcodes can be added to B’SST (GitHub - dgpv/bsst: B'SST: Bitcoin-like Script Symbolic Tracer) and what limitations of the (totaly unstable and undefined at the moment) API it would uncover.
I don’t have any preference for this or that opcode, but I have chosen
CHECKCONTRACTVERIFY because it has plenty of rules it imposes on its arguments, and GitHub - halseth/mattlab repo had some scripts that use the opcode, that I can use to test the plugin.
Writing the plugin helped to uncover some wrinkles with B’SST, which can be ironed out in the future, so I think writing plugins for other opcodes might help uncover more wrinkles.
You can find B’SST plugin for
CHECKCONTRACTVERIFY at B'SST plugin for CHECKCONTRACTVERIFY · GitHub
bsst-cli with this plugin:
/bsst-cli --op-plugins=examples/checkcontractverify_op_plugin.py (assuming the file is placed in the
examples dir). For now, to also have access to
CAT you need to enable Elements mode with
--is-elements=true. In the future, I may add a setting to selectively enable opcodes.
If you think you could use B’SST to experiment with your preferred opcode and think that it would be convenient to have a plugin for it, please write below the name of the opcode and a link to reference implementation. When I have another chunk of free time, I might implement more plugins.
I need a link to the reference implementation because figuring out the constraints an opcode puts on values is much easier when looking at reference code, but it is sometimes not easy to locate a reference implementation for someone who do not track the development very closely, and I can say that I don’t track that closely.
This is neat. I did run into
<n> OP_ROLL giving an error when
<n> wasn’t static, which I guess is understanable, but also disappointing.
In principle, it is possible to analyze non-static
PICK to some degree.
I’m not sure how practical it is, though, and if it is worth it putting the effort to allow this.
Each value of
ROLL will require its own execution path.
bsst could put some upper limit on
<n>, generate that many execution paths, analyze them one by one, and then show them in the report as ‘branches’ with conditions like
<n> = 1,
<n> = 2, etc.
<n> 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
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.
Can you give some examples of the practical scripts with non-static arg for
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
Without an opcode like that,
n is effectively static, since you need to consume all but one element from the stack, and each opcode consumes a constant number of elements. Perhaps
CHECKMULTISIG could do it, but that’s not available in tapscript, of course.
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
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.
Thanks for the example. I created an issue on
bsst github to describe this proposed improvement of analysis: Add ability to analyze dynamic arguments for opcodes like ROLL · Issue #14 · dgpv/bsst · GitHub
In the development version of bsst (and upcoming version 0.1.2) plugin system was reworked, and the way to run the referenced plugin slightly changed. Now it has to be run with
./bsst-cli --plugins=plugins/op_checkcontractverify_bsst_plugin.py. The
CAT opcode can now be enabled also via
The github gist with the plugin was also updated to work with new version.
(I would prefer to edit the first post to update the info, but it seems that I cannot)
(edit 29-11-23: updated the gist again)