--- Day changed Fri Oct 02 2020 01:13 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 01:35 -!- Ed0 [~edouard@2001:41d0:401:3100::4897] has joined ##miniscript 01:51 -!- jonatack [~jon@37.170.2.30] has joined ##miniscript 03:16 -!- jonatack [~jon@37.170.2.30] has quit [Ping timeout: 256 seconds] 04:03 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-qpjljywbagpaubig] has quit [Quit: Connection closed for inactivity] 04:37 -!- jonatack [~jon@88.124.242.136] has joined ##miniscript 04:42 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 258 seconds] 04:43 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript 07:32 -!- sgeisler [sid356034@gateway/web/irccloud.com/x-yqohwunudjlllidy] has quit [Ping timeout: 244 seconds] 07:34 -!- sgeisler [sid356034@gateway/web/irccloud.com/x-bdqmskrugramvupb] has joined ##miniscript 07:40 -!- Netsplit *.net <-> *.split quits: Aleru, felixweis 07:40 -!- Netsplit over, joins: Aleru, felixweis 07:47 -!- Aleru [sid403553@gateway/web/irccloud.com/x-yujxdzfveoxjwazt] has quit [Ping timeout: 244 seconds] 07:50 -!- Aleru [sid403553@gateway/web/irccloud.com/x-keznkmdiyphtgnhl] has joined ##miniscript 07:50 -!- felixweis [sid154231@gateway/web/irccloud.com/x-krefugjevbfmhthz] has quit [Ping timeout: 244 seconds] 07:53 -!- felixweis [sid154231@gateway/web/irccloud.com/x-obqpsjwlqqjjaomn] has joined ##miniscript 09:52 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 10:11 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 10:47 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 12:15 < jeremyrubin> Policy question: 12:16 < jeremyrubin> suppose I want to output a tree of Or's where each leaf has the same chance of satisfaction, is there a convenient way of doing this if the size of the tree is not known in advance? 12:17 < sanket1729> Do you know the structure of the tree? 12:17 < jeremyrubin> I don't care about the structure of the tree 12:17 < jeremyrubin> so I could do e.g. CONS style or tree style 12:18 < jeremyrubin> OR(OR(A, B, OR(C, D)) OR(A, OR(B, OR(C, D)) 12:18 < jeremyrubin> if I were to naively set each to relative odds 1 12:18 < jeremyrubin> then solution A would be 'fair' and solution B would make D much less likely 12:18 < jeremyrubin> if I understand correctly 12:19 < sanket1729> I think you would have to calculate the odds leaf to root. 12:19 < jeremyrubin> Yeah, which is sort of odd 12:20 < jeremyrubin> because that implies no online algorithm 12:20 < jeremyrubin> of course could always do Thresh(1, ....) but then that would have O(N) dissats 12:21 < jeremyrubin> Thresh could be tweaked to check the cost of an OR tree if k=1 is set 12:22 < sanket1729> One of the problems with converting thresh() to or() is that the compiler complexity is exponential in ORs 12:24 < jeremyrubin> ah right 12:25 < jeremyrubin> I guess the key observation is this: 12:26 < jeremyrubin> Thresh(1, ....) always outperforms OR(OR(...),...) because the IF ELSE wrappers are at least 2 bytes *N 12:26 < jeremyrubin> even if you have only log N dissats to select a branch 12:26 < jeremyrubin> you lose because the script, which goes in the witness, is O(N) bigger 12:26 < jeremyrubin> so thresh should always be better 12:27 < sanket1729> I don't think it's that simple 12:27 < sanket1729> thresh can perform better, because ORs have lot of freedom in terms of wrappers they accept 12:27 < jeremyrubin> If you need wrappers around the types I guess 12:27 < jeremyrubin> hmm 12:27 < jeremyrubin> which for CTV I would need 12:28 < sanket1729> thresh requires things to expressions that output unit type on the stack. 12:29 < jeremyrubin> Well I guess at least it's never *asymptotically* worse 12:29 < jeremyrubin> which is what I care about 12:29 < sanket1729> yeah 12:30 < jeremyrubin> Wasn't there something funky where we banned thresh with k = 1? 12:30 < jeremyrubin> or K=n? 12:30 < sanket1729> I have to fix the c++ version to support that. 12:30 < sanket1729> It's not banned in rust-miniscript. 12:32 < sanket1729> What is your `n` that online algorithm is a concern? 12:33 < sanket1729> nevermind, you cannot use the compiler for very large `n` anyways. 12:33 < jeremyrubin> it's not about N being large 12:34 < jeremyrubin> it's just about compilation being able to run as a 'forward pass' 12:34 < jeremyrubin> e.g., if I'm accumulating some tokens or something, can I directly convert to ORs 12:34 < jeremyrubin> or do I need to accumulate a vector of sub clauses 12:35 < jeremyrubin> I think Threshold is better anyways 12:35 < jeremyrubin> because it makes it more clear when eventually taproot 12:35 < sanket1729> yeah 12:36 < jeremyrubin> but perhaps threshold should take probs 12:36 < jeremyrubin> so that you can use it to structure taproot tree 12:36 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 12:37 < sanket1729> yeah, we havn't much thought about policy compiler for taproot. But clearly, thresh(k=1) is exactly what taproot is for. 12:40 < jeremyrubin> interestingly for AND clauses the tree structure doesn't matter at all because they just get concat'd 12:42 < sipa> the C++ compiler will try compiling thresh(1,...) to a cascade of ORs (with uniform probability for every leaf) 12:42 < sipa> and thresh(N,...) to a cascade of ANDs 12:42 < sipa> s/to/as/ 12:49 < sipa> (but it only tries one configuration, to avoid exponential blowup) 12:58 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 13:01 < jeremyrubin> Interesting! 14:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 15:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Read error: Connection reset by peer] 15:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 20:14 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 23:04 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 23:05 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript