--- Log opened Wed Feb 02 00:00:48 2022
00:14 < darosior> We don't that's why i just pulled out 90 which was indirectly the former value you used through the complexity
00:20 < darosior> Actually any W expression needs at least one OP being executed, so even with 100 subs you'd get to the limit: 100*W + 99*ADD + EQUAL
00:34 < darosior> Btw if anyone has a naming suggestion for NodeType / Type following Andrew's comment..
00:39 < darosior> Maybe s/NodeType/Fragment/
00:58 < darosior> Oh i had forgotten to add the properties..
00:58 < darosior> (in the fuzz target PR)
08:36 -!- rishabh [~rishabh@14.139.82.6] has joined ##miniscript
08:53 -!- rishabh [~rishabh@14.139.82.6] has quit [Quit: Ping timeout (120 seconds)]
08:55 -!- salvatoshi [~salvatosh@lfbn-idf3-1-709-208.w86-252.abo.wanadoo.fr] has joined ##miniscript
09:22 -!- salvatoshi [~salvatosh@lfbn-idf3-1-709-208.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 250 seconds]
10:45 < darosior> Ouch
10:45 <@sipa> Indeed.
10:45 <@sipa> I suspect the ops counting is wrong somewhere.
10:50 < darosior> Ooh
10:50 < darosior> The MULTI
10:52 <@sipa> https://0bin.net/paste/RbVnQHf2#xPxz5cNAGd-Kj4jCZDVWhTFPNooOYJTZOG4k949meE5
10:52 <@sipa> the and_n loses the dissatisfaction cost there
10:52 <@sipa> trying to figure out if that is right
10:54 < darosior> I think it's in the multi. We use the number of keys in CalcOps(). It's wrong, it should be 20 if >16
10:54 <@sipa> The 20 is there.
10:55 <@sipa> It's a multi with 20 keys.
10:56 < darosior> Yeah, right, sorry
10:56 <@sipa> Though what you're saying may be correct too.
10:56 < darosior> But still i think CalcOps() isn't right here, i'll look into it tomorrow 
10:56 <@sipa> Agree.
10:57 <@sipa> darosior: What if you do a thresh with 200 subs that are all 1?
10:57 <@sipa> OP_1 doesn't count an op.
10:57 < darosior> But it's not W?
10:58 < darosior> It needs at least a SWAP
10:58 <@sipa> Oh, right, it needs an s: at least.
10:58 <@sipa> That's not actually necessary in this case, but it's the best miniscript can model.
13:12 -!- Netsplit *.net <-> *.split quits: paairs, fjahr, elsirion, achow101, darosior, michaelfolkson, roconnor, sanket1729, hugohn, FelixWeis,  (+15 more, use /NETSPLIT to show all of them)
13:13 -!- Netsplit over, joins: achow101, hugohn, sandipndev
13:13 -!- Netsplit over, joins: michaelfolkson, _aj_, robertspigler
13:14 -!- Netsplit over, joins: blkncd, ademan[m], sanket_cell, MatrixBot12, dr-orlovsky, darosior, sanket1729
13:14 -!- Netsplit over, joins: roconnor
13:14 -!- Netsplit over, joins: andytoshi, @sipa
13:14 -!- Netsplit over, joins: sebx2a
13:15 -!- Netsplit over, joins: fjahr, _0x0ff, paairs
13:15 -!- Netsplit over, joins: elsirion
13:15 -!- Netsplit over, joins: FelixWeis, notmandatory_
13:15 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has quit [Ping timeout: 240 seconds]
13:15 -!- Netsplit over, joins: ksedgwic, midnight_
13:15 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Ping timeout: 245 seconds]
13:15 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 240 seconds]
13:15 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Ping timeout: 252 seconds]
13:32 -!- sipa [~sipa@user/sipa] has joined ##miniscript
13:32 -!- mode/##miniscript [+o sipa] by ChanServ
14:11 < sanket1729> Caught up with everything here :) 
14:11 < sanket1729> I believe we need some consensus on https://github.com/bitcoin/bitcoin/issues/24114 before miniscript integration?
14:13 < sanket1729> Also another nit: I would like relying on 200 op code limit for anything because it would make it difficult to extend to tapscript. 
14:15 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined ##miniscript
14:30 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined ##miniscript
14:40 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has joined ##miniscript
15:27 <@sipa> Trick: don't actually validate against the miniscript->ToScript(), but that prepended with (201 - miniscript->GetOps()) OP_NOPs.
15:28 <@sipa> So if the ops count is even slightly off, it'll trigger an error at validation time.
16:37 <@sipa> Found the issue. It's annoying.
16:37 <@sipa> The problem is that the ops computation only takes the operation of the non-malleable signing algorithm into account.
16:38 <@sipa> But the malleable signing algorithm sometimes does weird stuff.
16:38 <@sipa> In this case, it's choosing to satisfy a certain branch involving a multi() because it has the keys, and that's actually cheaper than dissatisfying it.
16:39 <@sipa> And this leads to an ops count that's higher.
16:39 <@sipa> sanket1729: I vaguely recall we knew about this, or something like it. Do you recall?
16:39 <@sipa> andytoshi too
16:41 < andytoshi> sipa: it sounds familiar. i think we encountered something like this. but no, i don't remember any specifics
16:41 < andytoshi> i think it was in one of our explorations into available/unavailable/maybe keys, or something like that, where i came up with a "simple" algorithm for handling it and then you shot it down, for a reason like this
16:41 < andytoshi> i don't think we came up with a good solution (or even a good problem definition)
16:43 <@sipa> One solution is just making the ops computation take all possible sats/dsats into account, including known to be non-canonical ones.
16:44 <@sipa> But for non-malleable signing (which I think we care far more about) that may overshoot significantly.
16:46 <@sipa> Maybe there is something slightly smarter, and have the signing algorithm keep track of the ops counts in the satisfactions/dissatisfactions it produces.
16:47 <@sipa> And when those exceed the statically computed ops counts for a particular branch, disregard those.
16:48 <@sipa> or just have the malleable signing algorithm prefer canonical solutions still, if they exist
17:03 <@sipa> that does seem to fix: when satisfying in malleable mode, if there are two "YES"es, and one is non-canonical, pick the canonical one
17:03 <@sipa> i suspect that more complicated cases may exist where this is not sufficient, though
17:03 <@sipa> going to let the fuzzer run overnighy
17:32 <@sipa> actually, i think this is sufficient
19:09 < sanket1729> I don't think we should only consider the assertion executed_ops < GetOps() only for malleable signing. 
19:10 < sanket1729> Recall that for non-IsSane things, signing may or may not work
19:11 < sanket1729> Whenever we construct a malleable solution, we always have to double check that the solution is acceptable (it might have more than 100 elems, might have more weight etc)
19:13 < sanket1729> With this in consideration we should only have assertions about opchecks, size check, script size check on non-malleable algorithm
19:13 < sanket1729> Pasting logs
19:13 < sanket1729> [18:15:56] <sipa> but the (malleable) signing algorithm i think should always be able to construct a valid witness, if one exists
19:13 < sanket1729> [18:16:24] <sanket1729> For example, it may choose a witness for 100 elements with less weight than one the 80 elements and more weight
19:13 < sanket1729> [18:16:52] <sanket1729> I don't see how we can easily do this, without storing min possible weight for each possible stack element count
19:13 < sanket1729> [18:21:22] <sipa> oh, i see
19:13 < sanket1729> [18:21:25] <sipa> good point
19:13 < sanket1729> [18:22:41] <sipa> fair point, i agree, that's very hard to do
19:13 < sanket1729> [18:23:09] <sipa> i guess the answer is just for-non-IsSane(), all bets are off; signing may or may not work
19:13 < sanket1729> [18:23:23] <sanket1729> Agreed
19:15 < sanket1729> I see that is unrelated to the above issue, but the point is that we want to avoid making any claims about nonIsSane(which includes malleable) things. 
19:27 <@sipa> I think we actually can guarantee the ability to sign for non-IsSane scripts that typecheck.
19:27 <@sipa> Though not necessarily at minimal cost.
19:28 <@sipa> I don't think this really matters though... this is for situations where you're given a bizarre script you'd probably never have a agreed to in the first place if you had a chance.
19:29 <@sipa> Well, typecheck and opscheck and stackcheck and all those things.
19:30 <@sipa> But specifically malleability shouldn't interfere with our ability to sign.
21:22 <@sipa> No fuzzing failures so far (this is fuzzing to construct arbitrary miniscripts, and then invoking the satisfier and giving the result to the script interpreter)
23:25 -!- Netsplit *.net <-> *.split quits: roconnor, FelixWeis, notmandatory_
23:28 -!- Netsplit over, joins: FelixWeis, roconnor, notmandatory_
23:42 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
23:58 < darosior> sipa: since you let the fuzz target run, if you still don't have any crash when you wake up can you merge and upload your corpus somewhere so i can merge it with mine?
--- Log closed Thu Feb 03 00:00:48 2022