--- Log opened Sat Jan 14 00:00:15 2023
01:48 < darosior> benma: not sure whether you got the response to your initial question. Maybe you know already but let me explain why we have these separate counts in the first place. The maximum number of opcodes in a script is 201. This check is done by the interpreter before branching on whether to execute the opcode currently read:
01:48 < darosior> https://github.com/bitcoin/bitcoin/blob/8915e4d9f5b7e360f70d2f67baa99cca451a10da/src/script/interpreter.cpp#L450-L453 (check for max ops), https://github.com/bitcoin/bitcoin/blob/8915e4d9f5b7e360f70d2f67baa99cca451a10da/src/script/interpreter.cpp#L482 (branch on whether to execute the current opcode). But in the specific case of CHECKMULTISIG, the
01:48 < darosior> number of opcode may be incremented *after* branching of fExec! https://github.com/bitcoin/bitcoin/blob/8915e4d9f5b7e360f70d2f67baa99cca451a10da/src/script/interpreter.cpp#L1118-L1120. This means that the number of opcodes will depend on what spending path is chosen. Counting all multi()s as always executed would be overly restrictive and prevent
01:48 < darosior> using, albeit large, potentially reasonable scripts.
02:07 < benma> darosior: i see that logic, but i fail to come up with a reasonable script that contains a multisig which is never executed. if it is never executed, it may as well be removed from the script.
02:18 < darosior> benma: it's not never executed. It's just that they aren't all executed *at once*
02:19 < darosior> For OP_IF <X> OP_ELSE <Y> OP_ENDIF either you execute X or Y, but not both at once. It's what we mean by unexecuted here
05:33 < benma> darosior: i don't think that's true. for the ops count, you need to consider the worst case, as it has to be below the limit under all circumstances (all possible satisfactions). 
05:35 < darosior> benma: yeah and often the worst case is not the addition of all paths as if they were all executed at once. For instance take `or_i(multi(20,k1,k2,...,k20),multi(20,k'1,k'2,..,k'20))`. The worst case executed ops here is always 25, not 45.
05:52 < benma> i am aware, but still, both lhe left and right expressions are accounted for by `max(ops(left), ops(right))`, as either left or right can be executed. in this case, the part of the CalcOps algorithm that checks if the multi's are part of any satisfaction (to determine if the key ops should be counted) is not needed.
05:53 -!- salvatoshi [~salvatosh@lfbn-idf3-1-333-227.w83-199.abo.wanadoo.fr] has joined ##miniscript
06:10 <@sipa> Hmm, can you suggest an actual patch that would make the simplification you're thinking of?
06:11 <@sipa> That may be easier to help find a concrete non-useless case where the difference matters.
06:11 <@sipa> Or alternatively, convince us that it's harmless
06:14 < darosior> benma: but you can't simply do max(ops(left),ops(right)) because some ops are always counted no matter what path is chosen. You necessarily need to account separately for the "static ops count" and the "dynamic ops count". But i agree with sipa, i'd be interested in seeing a patch, maybe i'm missing something.
06:33 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
06:35 -!- jon_atack [~jonatack@user/jonatack] has joined ##miniscript
06:53 < benma> darosior: i think you are missing my point. as an exercise, try to come up with a miniscript that contains a multisig, in which the max ops count does not include the number of keys in that multisig. you will see that this only happens if the multisig is *never* executed, in which case it could also be just omitted from the miniscript
06:56 < benma> if you assume every multisig that is present in the miniscript could be executed in one of the satisfactions, the keys in it need can be counted towards the max op unconditionally, which would simplify the CalcOps algorithm a lot
07:00 <@sipa> Hmm, I really don't see how that follows.
07:01 <@sipa> Knowing what exactly you mean to do instead would really help.
07:04 < benma> gotta go now unfortunately - i'll follow up with a hopefully clearer explanation
08:09 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
08:12 -!- jon_atack [~jonatack@user/jonatack] has joined ##miniscript
09:31 < benma> darosior: you were not missin my point, i was missing yours! i took more time to properly understand this thing and now i think i get it. sorry for wasting everyone's time :x 
09:32 < benma> if i find time to write a blog post about all of this, i'll be sure to explain it so the next person looking at this will hopefully have an easier time :)
09:40 <@sipa> @benma No worries, I'm glad someone is actually having a deep look!
10:22 < benma> thanks. one of the surprises i had is that in if..else..endif, also unexecuted op codes are counted. does that have a good reason, or is it basically simply not worth the effort to code an exception for?
10:22 < benma> (back then, of course changing it now makes no sense)
10:24 <@sipa> You'll have to ask satoshi.
10:25 <@sipa> Tapscript doesn't have ops limits anymore.
10:39 -!- kalle [~quassel@user/kallewoof] has quit [Ping timeout: 252 seconds]
10:48 -!- kalle [~quassel@user/kallewoof] has joined ##miniscript
14:20 -!- salvatoshi [~salvatosh@lfbn-idf3-1-333-227.w83-199.abo.wanadoo.fr] has quit [Ping timeout: 248 seconds]
17:58 -!- jon_atack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
17:58 -!- jon_atack [~jonatack@user/jonatack] has joined ##miniscript
18:52 -!- benma [~benma@2a02:168:5366:0:f7c2:b229:3cc7:8874] has quit [Ping timeout: 264 seconds]
--- Log closed Sun Jan 15 00:00:16 2023