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...