--- Log opened Sat Oct 07 00:00:50 2023
03:27 < darosior> Yes but the exec depends on the netdiff
03:28 < darosior> You can't think of both as being completely independent
03:29 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
04:14 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
05:06 <@sipa> darosior: yes, but exec depends on the value netdiff takes on at various points during execution
05:07 <@sipa> it doesn't only depend on the final one
05:15 <@sipa> darosior: let's try something else; given the + and | operator on SatInfo as they are defined, do you agree ((a | b) + c) is the same as ((a + c) | (b + c))
05:15 < darosior> sipa: sure
05:21 <@sipa> so the final output is really ((op_a1 + op_a2 + ... op_an) | (op_b1 + op_b2 + ... + op_bn) | ...), where the op_a* and op_b* are all different execution traces through the overall script
05:21 <@sipa> with the individual op_* being the corresponding SI_ constants (except for thresh, where it's implemented by hand, but still equivalent)
05:24 <@sipa> makes sense?
05:25 < darosior> Yes
05:27 <@sipa> ok, it's also true that (a + b + c) = ((a + b) + c) = (a + (b + c))
05:27 <@sipa> so this addition operator for SatInfos is associative
05:28 < darosior> Yes
05:28 <@sipa> it's not true that a + b = b + a, though
05:29 <@sipa> e.g. "<1> DROP" and "DROP <1>" have the same netdiff, but different exec (1 vs 0, respectively)
05:29 < darosior> Sorry, just give me a minute to think about it
05:30 < darosior> About the associativeness too
05:32 <@sipa> so a way to see it is that (a + b + c) has a netdiff that's the sum of all 3 netdiffs, and exec is the maximum of the netdiffs of (nothing), of (c), of (b+c), and of (a+b+c)
05:33 <@sipa> and that holds regardless of whether you compute it as (a+b)+c or as a+(b+c)
05:34 < darosior> Yes, ok
05:34 < darosior> I'm good
05:34 <@sipa> ok!
05:35 < darosior> I mean for the associativeness
05:36 <@sipa> so with that, our final output is an | of all execution traces through the script, and each trace computes (a) the overall netdiff for that trace through the script, and (b) the exec, which is the highest value that the netdiff reached through the script
05:37 <@sipa> and | between all those gives us (a) thr highest possible netdiff any trace through the script may have and (b) the highest possible netdiff any trace through the script may have reached (but not necessary the same trace as the one (a) originated from)
05:37 < darosior> That makes a lot of sense.
05:38 < darosior> Ok, i'll reflect on why my intuition was wrong. Thank you for taking the time to explain it to me step by step in another way
05:40 <@sipa> i struggled with this too, while i was writing it i was thinking "wait, this can't be always be correct"
05:40 <@sipa> but i think i've convinced myself now
07:01 <@sipa> darosior: i'm writing up a longer comment trying to explain this that can be pasted in the code
07:02 < darosior> Sounds good
08:16 < darosior> sipa: have you had the chance to go through the rest of the PR yet?
08:17 <@sipa> darosior: yeah, though i want to do the later ones in more detail still
08:17 < darosior> Ok
09:04 <@sipa> darosior: see last commit of https://github.com/sipa/bitcoin/commits/tapminiscript
09:14 <@sipa> darosior: for GetStackSize and GetExecStackSize, we perhaps should only add 1 for B, K, or W expressions (but not for V expressions)
09:15 < darosior> Right
09:15 < darosior> I'll do this
09:16 <@sipa> i think without that, there is a tiny possibility of incorrectly rejecting a valid miniscript which has a V subexpression that just reaches the stack limit
09:25 < darosior> How so? We only ever call `GetStackSize` on top-level which can't be V
09:26 <@sipa> Ah, indeed.
09:26 <@sipa> It's also called in FindInsaneSub, but that's only invoked if the toplevel is already insane
09:27 <@sipa> The compiler code (if we ever rebase it...) may also be invoking such checks at the individual expression level, to weed out excessive constructions early.
09:28 < darosior> Ok. I'm less familiar with the compiler
09:41 < darosior> Why do you call operator| the union while it actually chooses between one the two sets of execution, while i would have expected union would "merge" them so to speak
09:41 <@sipa> the union of two sets is just the set with all elements of both
09:41 <@sipa> it's not choosing between one or the other - it's computing statistics over a new bigger set
09:42 < darosior> Ok
09:42 <@sipa> this distinction is especially relevant, because the netdiff and exec value don't necessarily originate from the same element of the set
10:41 < darosior> Alright, pushed the latest cleanups. I'll soon be afk but will be back in a few hours, i'll address comments then if there is any.
10:42 <@sipa> i'll do more review while you're afk
10:59 < darosior> Awesome, thanks
12:59 <@sipa> darosior, achow101: i haven't followed taproot/psbt, is there any interaction (needed) between the newly added SignatureData::tap_pubkeys
12:59 <@sipa> and PSBT fields
13:00 < achow101> I don't think so, and I think it's tested
13:01 <@sipa> i'm not sure it can be tested fully, as the bitcoin core signer clearly wouldn't need such fields (it only signs when it has full descriptors for the outputs being spent)
13:02 <@sipa> but say an or_i(pkh(A), pk(B)) descriptor, with an updater that has access to pubkeys A and B, and a signer that only has privkey B
13:02 < achow101> it looks like the pr has FillSignatureData put the keys into tap_pubkeys anyways
13:04 <@sipa> a non-bitcoin core signer, i mean
13:05 < achow101> it should all work so long as the updater puts the keys into the tap_bip32_paths field
13:06 < achow101> which it figures out by dummy signing
13:07 < achow101> actually, i'm not totally convinced that tap_pubkeys is necessary
13:11 <@sipa> right, of course - it's the dummy signing that fills the psbt structures
13:13 <@sipa> achow101: i think it may work to put the corresponding even CPubKey into misc_pubkeys, as long as they're hashed in xonly form, but that's pretty ugly
13:20 < achow101> oh right, pkh
13:21 < achow101> i see that a test does fail if it is removed. and it needs to exist so that we can lookup the xonly pubkey given its hash
13:22 < achow101> anyways, I think the only interaction that's necessary is what's been implemented
13:41 <@sipa> sounds good
16:00 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
16:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined ##miniscript
17:37 -!- achow101 [~achow101@user/achow101] has quit [Remote host closed the connection]
17:38 -!- achow101 [~achow101@user/achow101] has joined ##miniscript
21:49 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
21:49 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined ##miniscript
--- Log closed Sun Oct 08 00:00:50 2023