Dmitry Petukhov

> > If you do not care about the facts that script might be doing something irrelevant, like checking a condition that is always true, then ignoring them doe not...

I think it would be great to detect 'effect-less' code fragments like `DUP DROP DUP DROP 2DUP 2DROP DUP DROP`, because it also can help detect the bugs, just like...

I am thinking that instead of ``` When GREATERTHANOREQUAL(wit0, 32) = 1 :: [IF @ 27:L12] ... When GREATERTHANOREQUAL(wit0, 32) = 0 :: [IF @ 27:L12] ``` it should be...

> > Hmm, this seems to be an always-true condition, and it should be possible to safely remove that condition, because it does not affect the results > > I...

Fixed in https://github.com/dgpv/bsst/commit/942f7bca3a360e22cf07b54818e0dfae80f33aae

I was thinking not about `OP_SUCCESS` itself, but about a cases where other opcodes can behave like `OP_SUCCESS` depending on their arguments. ~For example, upgradable pubkeys in tapscript. Right now,...

Regarding `OP_SUCCESS` itself, `bsst` do not recognize this opcode: there's no utility in analyzing scripts that contain explicit `OP_SUCCESS`, for exactly the reason that you have stated.

You're correct, I has mixed up the case of upgradable pubkeys (which only cause their sig check operation to succeed) with the behavior defined for `CHECKCONTRACTVERIFY`: https://github.com/Merkleize/bitcoin/blob/705dc9e41450edca86413710fc137906f6e5c949/src/script/interpreter.cpp#L1177 That was my...

Right now model values can show, for example, `tx_num_inputs` to be 100, but `current_input` to be 150. Readme tells about this, that model values are generated independently. But we actually...

We have the log of 'exec states' for each position of program counter, so we can compare current exec state with previous exec states to check if any previous state...