--- Day changed Mon Jul 20 2020 02:11 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:f56e:fb68:b894:e88d] has joined ##miniscript 03:03 < shesek> sipa, it would be great if the hash functions accepted any arbitrary name instead of only supporting 'H' (similarly to the pk function), I think the current behavior has the potential to confuse people 03:11 < shesek> I think I'm probably gonna have `hash(anything)` compile to `hash(H)` for now 03:55 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:f56e:fb68:b894:e88d] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:21 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 260 seconds] 05:24 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:40e9:2682:c291:8cb6] has joined ##miniscript 05:36 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:40e9:2682:c291:8cb6] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 06:13 -!- shesek [~shesek@188.120.133.185] has joined ##miniscript 07:57 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:a9ba:e7d1:8403:5903] has joined ##miniscript 08:14 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:a9ba:e7d1:8403:5903] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 09:19 < sipa> shesek: of course 09:20 < sipa> i should fix the demo code to support arbitrary strings there 09:26 < shesek> awesome, thank you 09:31 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:188a:4539:27a:a21e] has joined ##miniscript 11:04 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:188a:4539:27a:a21e] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 11:06 < sanket1729> sipa: I am looking at C++ implementation of miniscript, and the implementations considers thresh for k =1 or k =n as invalid miniscripts. 11:06 < sanket1729> In rust-miniscript, we allow those. 11:08 < sanket1729> I think that allowing k = 1 and k = n increases expression and hence we should allow it. But the website also clearly states condition 1 sanket1729: iirc that was done because it was much harder to get the type properties right otherwise 11:14 < sipa> and i don't think they're useful? a sequence of or_b or and_b will do the same, and be shorter 11:14 < sanket1729> Yes, true. 11:15 < sanket1729> I think we need to change our compiler too then. 11:15 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:188a:4539:27a:a21e] has joined ##miniscript 11:16 < sipa> ok, either or_b/and_b are shorter, OR multi is shorter 11:17 < sanket1729> Should the miniscript thresh be programmable in k, it seems that when someone changes 3-4 miniscript to 4-4 by changing k the suddenly it becomes invalid. 11:17 < sipa> that sounds like a pain :) 11:18 < sipa> malleability type properties of thresh depend on k 11:18 < sipa> so i don't think that's easily doable 11:22 < sanket1729> I am reexamining the rules. The only rule dependent on `k` is that s = "atmost (k-1) subs are non-s". There is nothing special about k = 1 or k =n that should make this rule wrong. 11:22 < sanket1729> Maybe, we are using k > 1 implicitly somewhere 11:27 < sipa> yeah, i can't remember the exact reason 11:27 < sipa> and i don't see why that constraint would be strictly needed now 11:30 < sanket1729> Yeah, I think we should allow k = 1 and k = n. That would also help us preserve the current implementation invariant of: policy -> miniscript -> abstract-policy == policy -> abstract-policy. 11:32 < sipa> that just means your abstract policy extractor isn't powerful enough :) 11:33 < sipa> it could use E[or(A,B)] = thresh(1,E[A],E[B]) 11:33 < sipa> and if both of E[A] and E[B] are thresh(1,something), aggregate them 11:33 < sipa> similar for and 11:33 < sanket1729> Yes, that works 11:34 < sipa> my compiler will turn thresholds in some cases into sequences of ors/ands 11:34 < sipa> so if you want to reason through that, you need a policy extractor that can do the same 11:34 < sanket1729> Does it only do for k=1 and k =n ? 11:34 < sipa> yes 11:35 < sipa> but i also want to support n-ary or/and, which will complicate things further 11:35 < sanket1729> I am planning to write an inefficient policy entailment logic which Russel mentioned. 11:35 < sipa> oh, this also means that in abstract policies you don't really need and/or, as they're exactly identical to thresh(1,...) or thresh(n,...) 11:35 < sanket1729> That would be inefficient, but should cover all cases where even trees are rearranged. 11:36 < sanket1729> Nice observation, in abstract policies there can only be thresh. 11:37 < sanket1729> So, I can implement a more powerful policy extractor. But I think we are still allowing k = 1 and k = n in thresh right? 11:38 < sipa> i don't see why not, except my hesitation to change things at this point :) 11:43 < sanket1729> creating an issue in your codebase for book-keeping. I can make a PR sometime this week. 11:43 < sanket1729> I am cross comparing the implementations modulo the compiler part. 11:43 < sipa> great 12:11 < jeremyrubin> Not sure what was actually agreed to from above, but thresh supporting 1 or n is definitely easier for script writers to reason about. 12:12 < jeremyrubin> And logically you could work around n by adding a provably dead key, and work around 1 by adding every key twice (maybe tweaked). 12:12 < jeremyrubin> (or by adding a key that is a public point is probably easier for 1) 12:13 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:188a:4539:27a:a21e] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 12:15 < sanket1729> We are supporting 1 and n for thresh. 12:15 < jeremyrubin> That's actually an interesting point, I wonder if you can get rid of and_* and or_* as actual things and replace them with i:thresh 12:15 < jeremyrubin> similarly to v:thresh transforms to verify 12:16 -!- shesek [~shesek@188.120.133.185] has quit [Ping timeout: 258 seconds] 12:16 < jeremyrubin> that way you could keep the language itself the same (as they are aliases) but the underlying data structures would only need 1 thresh combinator for thresh, and, or 12:16 < sipa> jeremyrubin: are you talking about miniscript or the policy language? 12:16 < jeremyrubin> similar to pk and vc:pk_h 12:16 < jeremyrubin> miniscript itself 12:16 < sipa> thresh is and has always been supported in tbe policy language 12:17 < sipa> no, the different and/or constructions have different type requirements and efficiency 12:17 < sipa> replacing them all with thresh would be a huge loss 12:17 < jeremyrubin> Ah I think you're missing what I'm saying, those constructions don't go away 12:18 < jeremyrubin> they just become deocrators like xy:thresh 12:18 < sipa> that seems silly 12:18 < sipa> they're different scripts 12:19 < sipa> with different requirements 12:20 < jeremyrubin> gotcha I was under the impression that the v: wrapper rewrites the tail of the script 12:21 < jeremyrubin> And I'm not proposing this to be silly, but that if you figured it out it's a very compact way to be able to represent n-ary and/or in miniscript as mentioned above 12:22 < jeremyrubin> but maybe you meant you only want that for policy? 12:23 < sipa> i don't think it's remotely reasonable to treat bla:thresh(1,X,Y) as or_c(X,Y) is now 12:24 < sipa> they have completely distinct type.properties 12:24 < sipa> so if you wantwd to do that, you'd need yet another intermediary representation that you convert to first, just in order to determine the types 12:46 -!- Tralfaz [~tralfaz@104.200.129.213] has joined ##miniscript 12:48 -!- Davterra [~tralfaz@104.200.129.62] has quit [Ping timeout: 256 seconds] 12:56 -!- Tralfaz [~tralfaz@104.200.129.213] has left ##miniscript ["Leaving"] 13:02 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 13:07 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 264 seconds] 13:09 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 13:13 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 240 seconds] 13:17 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 13:21 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 264 seconds] 13:25 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 13:30 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 258 seconds] 13:32 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 13:37 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 246 seconds] 13:39 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 13:44 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 265 seconds] 13:46 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 13:51 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 256 seconds] 13:55 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 14:00 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 256 seconds] 14:01 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 14:05 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 260 seconds] 14:09 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 14:13 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 258 seconds] 14:18 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 14:22 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 240 seconds] 14:23 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 14:28 -!- shesek [~shesek@5.22.128.126] has quit [Ping timeout: 240 seconds] 14:31 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 20:50 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-otyqznegmsqkmiol] has quit [Remote host closed the connection] 21:11 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-riveqdoqonlrguth] has joined ##miniscript