--- Day changed Wed Jul 08 2020
01:55 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]     
02:04 -!- kljasdfvv [~flack@p200300d46f11fb00d1f438c64543fc04.dip0.t-ipconnect.de] has joined ##miniscript     
02:04 -!- kljasdfvv [~flack@p200300d46f11fb00d1f438c64543fc04.dip0.t-ipconnect.de] has left ##miniscript ["Konversation terminated!"]     
02:51 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has joined ##miniscript     
02:52 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined ##miniscript     
02:57 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 256 seconds]     
02:58 -!- jonatack [~jon@213.152.162.5] has joined ##miniscript     
06:23 -!- jonatack [~jon@213.152.162.5] has quit [Ping timeout: 256 seconds]     
06:46 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Quit: ZNC 1.7.4+deb7 - https://znc.in]     
06:46 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##miniscript     
07:52 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
07:52 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##miniscript     
09:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript     
09:32 -!- sanket1729 [~sanket172@ec2-34-232-77-204.compute-1.amazonaws.com] has quit [Quit: ZNC 1.8.0 - https://znc.in]     
09:45 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##miniscript     
09:49 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
10:00 < jeremyrubin> So I'm working on some basic rust python bindings and have a quick question
10:00 < jeremyrubin> sanket1729: What's the difference between different MiniscriptKey trait types?
10:00 < jeremyrubin> E.g., String v.s. PublicKey
10:01 < sipa> keys in miniscript are abstract
10:02 < sipa> in the compiler they're just strings so they can be passed through from policy
10:02 < sipa> but you can't derive actual scriptpubkeys with them
10:02 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript     
10:02 < jeremyrubin> so with String it's an abstract ID
10:03 < jeremyrubin> and with Bitcoin::PubKey it's a concrete key?
10:05 < sipa> i assume so; i'm not familiar with the rust code
10:06 < jeremyrubin> Fair. Is there a reason why the Rust semantic policy uses 20 byte keyhashes and the concrete policy uses full keys, but you can't use keyhashes?
10:07 < jeremyrubin> sipa: sorry that these are rust questions :o 
10:27 < midnight> argh there's no +o in here and the channel is unregistered
10:27 < jeremyrubin> midnight: is there something you need to do with op?
10:28 < midnight> not at all, no.
10:28 < midnight> Just.. mentioning it in an open channel elsewhere will tend to get people joining it, and there's a few harassing criminals who might overhear and think they have a captive audience if they notice the channel is unreg'd.
10:29 < sipa> we'd move elsewhere
10:29 < sanket1729> Yes, bitcoin::PublicKey is the concrete key. 
10:30 < sanket1729> Here is an example using the compiler. https://github.com/rust-bitcoin/rust-miniscript/blob/master/examples/htlc.rs
10:39 < sanket1729> jeremyrubin: The mapping from policy to miniscript may change even between successive runs of the compiler. Does this affect your usage of the compiler?
10:39 < sanket1729> Currently, the Miniscript compiler produces the most optimal compilation in terms of average satisfaction costs, but the compiler internal uses non-deterministic HashMap traversal, it might produce two different compilations of the same average satisfaction cost. So, it is not advised to rely on policy compiler producing the same results
10:40 < sanket1729> Even the C++ and rust implementations may differ in actual miniscripts, but will have same average satisfaction costs. 
12:17 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]     
12:21 < jeremyrubin> Yeah I will likely want to modify it to be deterministic
12:21 < jeremyrubin> Or just cache the miniscript output
12:22 < jeremyrubin> but ideally I don't want to do that 
12:22 < jeremyrubin> I have a basic python binding setup which I'm now playing with :)
12:25 < jeremyrubin> Does policy currently not have a native multisig?
12:26 < jeremyrubin> It looks like Threshold only handles sub-policies and not native multisig
12:27 < sipa> at the policy level those are identical
12:27 < sipa> policy is the question "under which conditions can this be spent"; the choice of threshold vs OP_CHECKMULTISIG is a miniscript implementation choice
12:28 < jeremyrubin> I'm just trying to find where at the miniscript level the optimized output is made
12:28 < jeremyrubin> As in, it seems rust policy does not currently optimize this
12:28 < sipa> you mean the policy to miniscript compiler?
12:28 < jeremyrubin> Yeah
12:29 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-siipwwkhxjcfolyk] has joined ##miniscript     
12:29 < sipa> so there is no way to make it output multi(...) descriptors? that would be surprising
12:29 < jeremyrubin> not sure maybe I'm looking in the wrong spot for it...
12:30 < sipa> https://magicalbitcoin.org/repl/playground/ (which use rust-miniscript) produces thresh_m when i expect it to
12:35 < jeremyrubin> Ah I am getting multisigs out, just the logic is in some other file for that
12:37 < sipa> policies themselves have no concept of multisig
12:37 -!- felixweis [sid154231@gateway/web/irccloud.com/x-rwtspefaioxloplv] has joined ##miniscript     
12:41 < jeremyrubin> I understand the point you're making about policy compiler implementers having choice of compilation, but I don't think it's particularly useful to what I'm asking.
12:42 -!- hugohn [sid304114@gateway/web/irccloud.com/x-ybcpgnhejhwlosqh] has joined ##miniscript     
12:43 < jeremyrubin> I'm trying to ask specific questions about the policy compilers that exist rather than the general policy language
12:44 < jeremyrubin> My confusion on this point stems from a couple points
12:44 < sipa> you're trying to treat the policy compiler as normative
12:44 < jeremyrubin> if I want to do a multisig, I should do in *policy* thresh(2, pk(A), pk(B), pk(C))
12:44 < sipa> yes     
12:45 < jeremyrubin> This compiles to multi(2, A, B, C) in the concrete compiler
12:45 < sipa> yes     
12:45 < jeremyrubin> but in the Semantic one, we only have PKH
12:46 < jeremyrubin> So does it end up compiling multi(2, pk_h(A), pk_h(B), pk_h(C)) (iirc, pk_h is the thing that extracts a pk from a pkh)
12:46 < sipa> that makes no senze
12:47 < sipa> i assume that PKH is just used as a pubkey key identifier
12:47 < jeremyrubin>  /// Semantic policies store only hashes of keys to ensure that objects
12:47 < jeremyrubin>  /// representing the same policy are lifted to the same `Semantic`,
12:47 < jeremyrubin>  /// regardless of their choice of `pk` or `pk_h` nodes.
12:47 < sipa> not as a way of representing pk_h scriptz
12:47 < instagibbs> sipa, is your s key sometimes spitting out z?
12:47 < sipa> phone typing
12:47 < instagibbs> ah     
12:48 < jeremyrubin> So you need to run some sort of key mapping before compiling with that version?
12:48 < sipa> what do you mean?
12:49 < sipa> i think semantic policies are just a way of comparing/analyzing scripts
12:49 < sipa> not as a source for compilation
12:49 < sipa> though sanket1729 andytoshi probablg know this better
12:50 < jeremyrubin> I'm not really sure why I'd want that
12:50 < jeremyrubin> if I can't compile scripts from it
12:50 < jeremyrubin> Is it to load scripts generated by others?
12:50 < sipa> i believe so
12:51 < sipa> and i think that's also what you should be doing, instead of assuming deterministic compilation
12:51 < jeremyrubin> Ah, so you could have a tightly defined concrete compiler which only inputs/outputs from our side
12:51 < jeremyrubin> and then a loosely coupled input semantic compiler that should understand a bigger set of scripts, maybe from someone elses compiler
12:52 < sipa> so you can work with arbitrary scripts, and just vefify that it does what you want it to do
12:52 < jeremyrubin> sipa: I wish i could do that, but you'll have to beleive me for the time being that making that work (non deterministic compilation) would be a huge headache
12:52 < sipa> then perhaps miniscript isn't really what you need :)
12:53 < jeremyrubin> I don't see what's concretely wrong with having a normative/det compilation
12:53 < jeremyrubin> Can you say what the issue is with that?
12:53 < sipa> because i hope we'll improve the compiler!
12:53 < sipa> and extend miniscript too, perhaps
12:54 < sipa> *compilers
12:54 < jeremyrubin> That would be fantastic! But it seems lofty to hope that will be backwards compatible.
12:54 < sipa> and because there may be auxiliary information someone has that changes the optimal script, but doesn't fit in the currently accepted policy compiler
12:54 < jeremyrubin> V.s. just versioning the compilers
12:55 < sipa> why? i believe the c++ conpiler is already better in some cases than the rust one
12:55 -!- Aleru [sid403553@gateway/web/irccloud.com/x-bzlawewlmjbhxtqv] has joined ##miniscript     
12:55 < sipa> for example, a thresh but with probabilities on the (combinations) of branches
12:56 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-jbulpdnugspyzpyb] has joined ##miniscript     
12:56 < jeremyrubin> OK I hereby declare that I am forking Miniscript to produce Miniscript normative. And the optimality condition for Miniscript normative is being able to be deterministic on request.
12:56 < jeremyrubin> I think it's also good for testing
12:56 < jeremyrubin> Input this seed --> get this output
12:56 < sipa> the policy language can't express that, but it very well may affect what script is optimal
12:57 -!- schmidty [sid297174@gateway/web/irccloud.com/x-ckqifnzpczeptffn] has joined ##miniscript     
12:57 < jeremyrubin> You're saying compilation can't be a pure function, which is untrue
12:57 < sipa> i think that's silly because i think of the policy language and thr current compiler as a demo
12:57 < sipa> not as the final thing to declare miniscript
12:57 < sipa> the amazing thing with miniscript is being able to reason about arbitrary scripts that people give you, regardless of how they come up with them
12:58 < jeremyrubin> Yes! And that property is useful even with deterministic compilation and I have some cool uses for that!
12:58 < sipa> if you reduce all that to needing the policies they were compiled from you're massively restricting its possibilities
12:59 < sipa> like... miniscript was designed exactly so that that wasn't needed
12:59 < jeremyrubin> I see your point on that, but in this particular instance it isn't even nesc a peer to peer thing
12:59 < jeremyrubin> It's literally I want to be able to re-generate the same contract multiple times and get the same thing
12:59 < jeremyrubin> And not have to store all the data
13:00 < sipa> ok, going to stop commenting
13:00 < jeremyrubin> This is also important for being able to e.g. prove that something was compiled correctly
13:02 < jeremyrubin> That's fair, I'm not trying to badger you on this. But Miniscript is great and does 99% of what I need! But I also would like the ability to get deterministic compilations out, and I think there are real uses for that.
13:02 < jeremyrubin> we can just wait and see, maybe I'll implement something I think requires determinism and you'll have a clever way of not requiring it
13:03 < sipa> i am scared of an ecosystem developing that relies on knowing policies in this exact quick and dirty policy language for everything, and a compiler that can't evolve because of it
13:04 < sipa> my goal is eventual interoperability, and the layer at which things interact should be script/miniscript, not policies
13:05 < jeremyrubin> That's fair. May I make a suggestion in that case? It would be good to have two Policy languages. Policy deterministic IR and policy optimizing. The issue and reason I am abandoning the miniscript layer is that while my own stack can output deterministic miniscript things, it ends up being really brittle with all of the type modifiers
13:06 < jeremyrubin> Ran into a lot of challenge getting miniscripts as *compiler outputs* to compile because of getting proper wrapping of types and stuff
13:07 < jeremyrubin> you can't just blindly wrap clauses top down, you need to modify them to be passed correctly, and that's more complicated
13:07 < sipa> abstract policies get you the best of both world
13:07 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has joined ##miniscript     
13:07 < sipa> people can use whatever concrete policies they want when building scripts, but you can verify them against an abstract language
13:07 < jeremyrubin> Yes, that sounds fine. I'm just looking for a minimal concrete policy
13:08 < jeremyrubin> And I can either end up re-implementing my own version of this which is deterministic 
13:08 < jeremyrubin> or using one which is already written
13:08 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has left ##miniscript []     
13:11 < sanket1729> jeremyrubin, it does have native multi-sig. Threshold with multiple public keys would be compiled to Check multisig if that is the optimal compilation. 
13:14 -!- digi_james [sid281632@gateway/web/irccloud.com/x-acapbubtjyrfcjrf] has joined ##miniscript     
13:21 -!- sgeisler [sid356034@gateway/web/irccloud.com/x-ttewmwdpghvewxca] has joined ##miniscript     
13:29 < sanket1729> andytoshi: I do think we can change compiler to have BTree instead of HashMap so that we can atleast assure that across multiple runs of rust-miniscript compiler output would be the same
14:31 < sanket1729> sipa: It looks like the c:pk(K) aliases to cc:pk_k(K) typechecks correctly when it should not. 
16:54 -!- Davterra [~tralfaz@104.200.129.62] has joined ##miniscript     
16:55 -!- Davterra [~tralfaz@104.200.129.62] has left ##miniscript []     
17:07 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]     
17:08 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has joined ##miniscript     
19:22 -!- shesek [~shesek@5.22.128.126] has quit [Read error: Connection reset by peer]     
19:22 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript     
20:22 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has quit [Read error: Connection reset by peer]     
20:22 -!- dr_orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has joined ##miniscript     
22:25 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]     
22:35 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript     
23:55 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-jbulpdnugspyzpyb] has quit [Ping timeout: 246 seconds]     
23:55 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-xakextsjllqfoobo] has joined ##miniscript