--- Log opened Fri May 05 00:00:55 2023
00:21 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
01:37 < darosior> sanket1729_: hmm i don't remember us discussing the stack size tracking during the execution of a tapscript?
02:43 <@sipa> @darosior Do you want to add a snippet to the 25.0 release notes about miniscript signing support?
02:53 < darosior> sipa: i've done that in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/25.0-Release-Notes-Draft#250-release-notes-draft
03:14 <@sipa> Excellent.
03:16 -!- Guest33 [~Guest33@93-173-47-11.bb.netvision.net.il] has joined ##miniscript
03:17 -!- Guest33 [~Guest33@93-173-47-11.bb.netvision.net.il] has quit [Client Quit]
03:29 <@sipa> Hmm, should we also be adding some note in doc/descriptors.md to explain miniscript is supported too?
03:34 < darosior> I think so but i wasn't sure how to go about it
03:35 < darosior> Especially since 25.0 was branched-off already
03:41 <@sipa> Yeah I guess it'll only go in 26 then, or maybe a backport if there is one.
03:41 <@sipa> But the document is outdated now.
03:42 <@sipa> I started on a PR to add it a few weeks ago, but I think I tried to go into too much detail and didn't get very far.
03:42 < darosior> sanket1729_: so reading through the accounting of the stack size during execution of a fragment, you are not accounting for how fragments affect the size of the stack. For instance take `and_b(X, Y)`. You compute the stack size to be the greater between the stack size after execution of `X` and the stack size after execution of `Y`, plus one. Plus
03:42 < darosior> one because, i presume, because `X` must be of type B and push (at most) one element on the stack. But it may be largely overestimating. `X` may have popped dozens of elements from the stack before pushing 1 or 0 (think for instance a `multi_a`). Did you do that out of simplicity, to have conservative bounds?
03:43 <@sipa> On the other hand, whatever we write there, if sufficiently detailed, may be a good basis for a future miniscript-descriptors BIP.
03:44 < darosior> sipa: my thinking was that if we wrote something about Miniscript in doc/descriptors.md we would link to your website.
03:44 < darosior> Otherwise i was thinking we'd end up just rewriting most of what's already on the website
03:46 <@sipa> Forget descriptors.md; what kind of detail would we want in a miniscript-descriptors BIP.
03:46 <@sipa> ?
03:47 < darosior> Basically the "Miniscript reference" section of your website?
03:47 < darosior> Maybe without the satisfaction algorithm details if we want to keep it shorter
03:48 <@sipa> Do we support malleable miniscript in descriptors?
03:49 <@sipa> (in the current implementation)
03:49 < darosior> Not yet
03:49 < darosior> The Miniscript does support a malleable satisfier, but the descriptors code won't let you use it yet
03:50 < darosior> We could separate the correctness reference and the malleability analysis reference
03:50 <@sipa> Right, we talked about a way to mark descriptors as "dangerous" or so, so there could be a warning when importing them or so, which could be set for malleable ones.
03:51 < darosior> Yes i think we should do this
03:51 <@sipa> But with that, would you be ok to support importing them still.
03:51 < darosior> You could have a "force" parameter to importdescriptors to force importing unsafe descriptors
03:51 <@sipa> Yeah.
03:53 < darosior> So yeah i think we should let users import not sane, or incomplete, descriptors but not by default
03:54 < darosior> Because the same argument applies to partial descriptors. You may import, say, a tr() descriptor where you don't know some of the leaves and it's probably something we'd like to not accept by default
04:17 <@sipa> Yeah.
09:27 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 240 seconds]
13:04 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has joined ##miniscript
13:29 -!- jonatack1 [~jonatack@user/jonatack] has joined ##miniscript
13:30 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
14:25 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has quit [Ping timeout: 240 seconds]
14:45 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has joined ##miniscript
14:47 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has quit [Client Quit]
15:42 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
15:51 -!- jonatack1 [~jonatack@user/jonatack] has joined ##miniscript
20:24 < sanket1729_> darosior: Yes, X can pop off many elements during execution. Which is preciously why it is `max(X, Y + 1)`. The fragment only calculates the maximum stack size that can be reached, not the stack size after execution!
20:26 < sanket1729_> I would argue that those are even stricter bounds than what we need
20:27 < sanket1729_> We discussed some "score" metric that is much simpler to code and implement. 
20:27 < sanket1729_> So, the above discussion about exact calculation for max stack size is not relevant anymore. 
20:27 < sanket1729_> https://gist.github.com/sipa/06c5c844df155d4e5044c2c8cac9c05e#tapscript-miniscript
23:10 <@sipa> @darosior We've since decided to implement an exact stack size computation anyway instead of the score metric, if you scroll back a few months here :)
--- Log closed Sat May 06 00:00:53 2023