--- Log opened Fri Mar 10 00:00:07 2023
00:13 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
04:02 < darosior> The miniscript_smart fuzzer is very effective.. And the stack size tracking logic very tricky!
08:02 < darosior> salvatoshi, sipa: i'm having a discussion with the both of you in DMs on the same topic. Maybe let's share our thinking there altogether?
08:03 <@sipa> Hi.
08:03 < salvatoshi> hi! :)
08:04 < darosior> So we were discussing how to rule out scripts that would run into the stack size limit during execution under Tapscript.
08:07 < darosior> A while ago sipa suggested using a score metric https://gist.github.com/sipa/06c5c844df155d4e5044c2c8cac9c05e. I argued we might as well just track the stack size https://gist.github.com/sipa/06c5c844df155d4e5044c2c8cac9c05e?permalink_comment_id=4383517#gistcomment-4383517 since it's not more complicated and less restrictive. It's also what i
08:07 < darosior> implemented in https://github.com/darosior/bitcoin/pull/7.
08:07 < darosior> But salvatoshi we'd be interested in knowing how it would play out for signing devices that have less resources. But you already don't support all sane Miniscripts?
08:07 < darosior> Because of limitations you already have with P2WSH-Miniscript
08:08 < darosior> So in this case it's not even a concern for you, since you already have stricter limits. Am i right?
08:09 <@sipa> That suggests to me it may be worth defining a "resource restricted" subset of miniscript that's aimed for computationally weaker hardware.
08:11 < salvatoshi> there are roads for the fully solving the hardware limitations in the future, but at present: yes, we support a subset of miniscript policies that is "best effort". That is: whatever we can fit with the current technical limits, with plans to increase in the future as needed.
08:12 <@sipa> But perhaps that's somewhat of a wasted effort, as increasing powerful hardware may support increasingly large limit.
08:12 <@sipa> And any subset we'd want to define would be quickly outdated.
08:12 < salvatoshi> I'd say so, yes
08:12 <@sipa> I'm just slightly worried about unpredictable compatibility
08:14 < salvatoshi> I think that should more be a concern for hardware vendors. I currently have artificially low limits that allow me to be sure that a pretty large set of interesting policies are supported even on Nano S
08:17 < salvatoshi> I could have higher limits on the other devices, but no point in adding additional complexity before users hit those limits (which I deem unlikely, at least on segwit miniscripts)
08:18 <@sipa> What kind of limits are those?
08:18  * darosior afk, need to run unfortunately. I'll read the scrollback.
08:22 < salvatoshi> I have limits both the descriptor template as a string (which is not the descriptor; basically it doesn't include the keys); and I have a limit on the parsed in-memory representation of it (which is very implementation-specific). Currently I set the limits to 192 and 264 bytes (resp.) on NanoS, and 512 bytes for both on other devices.
08:27 < salvatoshi> so... pretty small compared to the space of valid miniscripts, but plenty to work with relatively complex policies in practice. I expect to increase these limits over time, especially because large taptrees start to make more sense in practice
08:28 <@sipa> I see, and limits of that order of magnitude aren't ever going to hit size/ops/stack limit anyway.
08:28 <@sipa> Though at some size that may become a concern.
08:29 < salvatoshi> yup; I implemented the stack limit from core for segwit-miniscript anyway, but only for future-proofing
08:29 < salvatoshi> note that the way wallet policies are implemented at Ledger, you'd know that you're not able to use a policy before you can use it in any way, because you have to register the policy first
08:30 < salvatoshi> vice-versa, if you can register the policy, then you can use it later.
08:30 <@sipa> That's a good property to have; at least it'll fail gracefully before it's a concern.
08:31 < salvatoshi> (might need to be careful with very deep taptrees, as currently it uses explicit recursion. Most likely I'll have a depth limit that is much smaller than 128 for now...)
08:32 <@sipa> There are some cool tree-walking algorithms that work with an explicit stack, FWIW.
08:44 < salvatoshi> btw while I have your attention: I'd love if you had any comments on wallet policies, that is a BIP proposal I'm trying to push forward: https://github.com/bitcoin/bips/pull/1389. They are a layer on top of descriptors that tries to exactly represent an "account" in a structured way that makes sense for software/hardware wallets.
09:22 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 255 seconds]
13:00 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has joined ##miniscript
14:24 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has quit [Ping timeout: 248 seconds]
14:39 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has joined ##miniscript
15:03 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has quit [Ping timeout: 268 seconds]
15:08 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has joined ##miniscript
15:36 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer]
15:37 -!- darosior [~darosior@194.36.189.246] has joined ##miniscript
15:40 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has quit [Ping timeout: 248 seconds]
15:50 -!- darosior [~darosior@194.36.189.246] has quit [Ping timeout: 276 seconds]
15:58 -!- darosior [~darosior@194.36.189.246] has joined ##miniscript
--- Log closed Sat Mar 11 00:00:08 2023