--- Day changed Thu Jul 09 2020 01:58 -!- dr_orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 01:58 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has joined ##miniscript 03:32 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 03:33 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined ##miniscript 06:46 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has quit [Read error: Connection reset by peer] 06:56 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has joined ##miniscript 08:48 -!- dr_orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has joined ##miniscript 08:48 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has quit [Read error: Connection reset by peer] 09:55 -!- meshcoll- [meshcollid@gateway/shell/ircnow/x-mckvnhdqwkgowycq] has joined ##miniscript 09:55 -!- Netsplit *.net <-> *.split quits: meshcollider 10:03 -!- dr_orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has quit [Read error: Connection reset by peer] 10:04 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has joined ##miniscript 11:18 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 11:18 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 12:05 -!- meshcoll- [meshcollid@gateway/shell/ircnow/x-mckvnhdqwkgowycq] has quit [Quit: ZNC 1.7.5 - https://znc.in] 12:06 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-otyqznegmsqkmiol] has joined ##miniscript 14:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 14:15 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##miniscript 15:23 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Bye] 15:25 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##miniscript 15:32 < andytoshi> 17: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? 15:32 < andytoshi> because when lifting to an abstract policy you don't generally have the public key 15:33 < andytoshi> so we either had to retain the distinction between public key/pubkeyhash in the abstract policy, or drop to the lowest common denominator 15:33 < jeremyrubin> gotcha that makes sense 15:34 < andytoshi> 19:45 < jeremyrubin> but in the Semantic one, we only have PKH 15:34 < jeremyrubin> I think when I asked that I didn't understand that the semantic policy doesn't have a compiler 15:34 < andytoshi> oh i see 15:34 < andytoshi> yes, there is no such thing as a "semantic compiler", semantic policies do not have enough information to compile 15:34 < andytoshi> basically they only have enoguh information to compare semantics :0 15:34 < andytoshi> :) 15:35 < andytoshi> 19:50 < jeremyrubin> I'm not really sure why I'd want that 15:35 < andytoshi> to analyze script semantics :P 15:35 < andytoshi> if you stick to pure minisrcipt then you can answer questions about witness creation and resource limits but you can't answer questions about e.g. how does the policy transform when various timelocks are up 15:36 < andytoshi> or when a certain pubkey is definitely able to sign, or definitely not able to sign, etc 15:36 < jeremyrubin> Yeah. My point of confusion was how multi() is handled if you only know PKH's 15:36 < andytoshi> if you only know pkh's there isn't a *ton* you can do beyond comparing scripts 15:36 < jeremyrubin> but it makes sense that at the semantic policy level thresh(.., pk(a)..) makes sense 15:36 < andytoshi> it's really unfortunate that lifting to semantic policies loses the original pubkeys 15:37 < andytoshi> we might revisit this decision post-taproot when we no longer expect contextless-scripts (e.g. what you find on the blockchain) to be liftable to something meaningful 15:37 < jeremyrubin> what is confusing still is if you write thresh(..., pkh(a), pkh(b), pkh(c)) concrete though what it compiles to, but that doesn't matter as long as it's correct 15:38 < jeremyrubin> because multi() expects to get bare keys, pkh should be able to work, it's just weird 15:38 < andytoshi> i can't parse what you said, but i think the only thing you should assume about the compiler is that its input and output lift to the same thing 15:38 < jeremyrubin> hm? I would expect that reverse compiling/lifting to not be inverse 15:39 < jeremyrubin> and(B, A) might e.g. be lossy and sort to and(A,B) 15:39 < andytoshi> oh yeah you have to canonicalize the policies to get uniqueness 15:39 < andytoshi> i forgot we don't do that by default 15:39 < andytoshi> because we don't want to assume everything can be ordered, by default 15:39 < jeremyrubin> maybe you do? not sure 15:39 < jeremyrubin> Still learning 15:40 < andytoshi> i don't think we do, because we want to work with pubkeys that don't impl Ord, as much as is possibly 15:40 < sanket1729> Policy ->(compile) -> miniscript -> lift(abstract policy) is same as policy ->(lift) abstract policy 15:40 < sanket1729> We don't normalize by default. We have additional function to do it 15:40 < jeremyrubin> btw to answer your q on https://github.com/rust-bitcoin/rust-miniscript/pull/109#issuecomment-656381786 15:40 < sanket1729> I guess we should call it in lift itself. 15:40 < jeremyrubin> A concrete example of where I want this is let's say that I'm running a lightning channel with you 15:41 < jeremyrubin> and it's really a state channel 15:41 < jeremyrubin> I send a patch to you, which is "pay alice 10 sats more in this part of the contract" 15:41 < jeremyrubin> And then you are like groovy, OK. 15:42 < andytoshi> sanket1729: we can't call it in lift itself 15:42 < andytoshi> because if Pk doesn't implement Ord we can't sort 15:42 < jeremyrubin> Using CTV, you can then update your replicated-state-machine to produce identical state trees for the patch 15:42 < jeremyrubin> And then just agree on the state root hash 15:42 < sanket1729> looking into it 15:42 < jeremyrubin> Not using CTV, you end up having to have a leader realy O(state) to the other (or, in some cases, all other) participants 15:42 < andytoshi> jeremyrubin: i really don't see the benefit to this 15:42 < andytoshi> vs you sending me the full diff and i just verify that 15:43 < andytoshi> but i guess if you want some minimalistic ad-hoc language just for op_ctv which is used to compress this communication 15:43 < andytoshi> that's fine and valuable 15:43 < jeremyrubin> the state trees can get quite large. 15:43 < andytoshi> but it's not miniscript-like at all 15:43 < andytoshi> i see yeah 15:43 < jeremyrubin> and you can have N participants 15:43 < andytoshi> it is not a design goal of anything in rust-miniscript (or pieter's C++ code) to achieve this 15:43 < andytoshi> this sounds like a specific compression application 15:44 < jeremyrubin> Ah 15:44 < jeremyrubin> Well so I'm giving a specific use case. 15:44 < jeremyrubin> Another area where it's useful is for non-interactive contract creation 15:44 < jeremyrubin> Let's say I have SuperLiquidAwesomePegin 15:44 < jeremyrubin> Which compiles to 10MB of stuff for a peg in, based on 100 bytes of input data 15:45 < andytoshi> i cannot imagine writing one piece of software that can handle both those use cases 15:45 < jeremyrubin> I can easily put the arguments to the function e.g. in an op_return on the tx, and then it's possible to re-derive all the state from that. 15:45 < andytoshi> they both sound very specific and like they have specific compression needs 15:45 < andytoshi> especially if the result should be on the blockchain! it needs to be as small as possible 15:45 < jeremyrubin> This is not specifically about compression 15:46 < jeremyrubin> Nah the state tree, not the result 15:46 < jeremyrubin> the tree can be log(state tree) 15:46 < jeremyrubin> err log(state tree) in execution 15:46 < sanket1729> andytoshi: We are already normalizing while lifting :) 15:46 < sanket1729> MiniscriptKey implements Ord 15:46 < jeremyrubin> andytoshi: and the point being less so about the compression in the above example and more so that it helps you non-interactively recognize a spend to you 15:47 < jeremyrubin> Which otherwise you need to e.g. run a server to learn of any deposits 15:47 < jeremyrubin> And then if you yourself lose all these 10MB state trees (which can become a lot of stuff to secure over time) then you can't re-derive the nodes 15:48 < jeremyrubin> So it's safer to have a deterministic scheme that you can just re-run to get any node you want 15:48 < andytoshi> sanket1729: oh lol nice 15:48 < andytoshi> to recognize policies you can lift to semantic policies 15:48 < andytoshi> it doesn't sound safer at all to assume determinism of a fundamentally non-unique map 15:49 < jeremyrubin> I agree, I'm not assuming it tho? 15:49 < andytoshi> what you are describing is compression 15:49 < jeremyrubin> I'm checking that the code is a unique map, and it seems that it currently is a unique map (after my patch) 15:49 < jeremyrubin> It's fine if it's a non-goal of the projects as they are, but coincidentally you've made something that's pretty good for this use case. 15:50 < andytoshi> it wasn't designed to be unique and it seems intractable to me to verify that it's unique 15:50 < jeremyrubin> Wait 15:50 < jeremyrubin> Can you define unique map? 15:50 < jeremyrubin> I just want it to be functional 15:50 < jeremyrubin> not invertile 15:50 < jeremyrubin> compile(x) == compile(x) seems very easy to check 15:50 < andytoshi> a unique map is a function 15:50 < andytoshi> forall x compile(x) == compile(x) is intractable 15:51 < andytoshi> it's probably not uncomputable 15:51 < andytoshi> but like, it might be 15:51 < jeremyrubin> Is there a practical counterexample you have right now? 15:51 < jeremyrubin> Nothing comes to mind that if they are pure functions the output would change 15:52 < andytoshi> i don't see why they'd be pure, they are not designed to be pure 15:52 < andytoshi> they certainly allocate memory 15:53 < jeremyrubin> hmm I think there are reasonable defs of purity which permit allocation. 15:54 < andytoshi> sure, but i don't want to go through the implementation of every data structure we used to check that they're met 15:54 < andytoshi> i suspect that the rust compiler can reorder floating point ops in ways that would result in some comparisons sometimes being flipped 15:55 < jeremyrubin> Ah so you think per-compile maybe functional, but not across compilations? 15:55 < andytoshi> that's not what i said 15:55 < jeremyrubin> per-compile of rust-miniscript 15:55 < andytoshi> i have made zero claims about purity, and i don't want to make any such claims, and i don't want to take any actions toward being able to make such claims 15:56 < jeremyrubin> So it sounds like the preference is for me to fork & maintain a deterministic version? 15:56 < andytoshi> if, after this discussion, you still want a deterministic compiler, then yes 15:58 < jeremyrubin> Does miniscript break compatibility between HD wallets used to do multisigs in lockstep? 15:58 < jeremyrubin> e.g., if I use the same derivation paths for all 2 of 3's among 3. 15:58 < jeremyrubin> Using miniscript would break the re-derivability of HD wallet? 15:58 < andytoshi> what? 15:59 < andytoshi> if you are using the same descriptor for all participants you will always get identical scripts 15:59 < jeremyrubin> ah so it's step1: create a policy. step2: create a miniscript. step3: create a descriptor, use that descriptor? 16:00 < jeremyrubin> steps 1 and 2 are not deterministic, and have to be done at setup time? 16:00 < andytoshi> yes 16:01 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-184-23.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:02 < jeremyrubin> does it seem unreasonable to want some step 1 and 2 (not miniscript based lets say) that are deterministic? 16:05 < andytoshi> it seems like you'd have really specific requirements if you wanted that 16:05 < andytoshi> and it seems unreasonable to want that *and* optimal compilation 16:06 < jeremyrubin> If you're non-adversarial on program input you can still use a fixed random seed 16:11 < jeremyrubin> I think it's also reasonable btw to make an effort toward but not guarantee of determinism. In the patch I suggested it should be at least useful in testing to be able to check if the compilation regressed in some unintended way. 16:12 < andytoshi> i still don't see the value in determinism, and i definitely don't see the value in "put effort into determinism but don't actually acheive it" 16:14 < jeremyrubin> Well if you suspect code might not be deterministic and you don't know how or where, it's useful to test that it won't fail in an unexpected way in some condition that it has previously worked. 16:15 < jeremyrubin> The more functionally pure code is, the easier it is to prove correct. 16:16 < jeremyrubin> If you do explicitly want it not to be deterministic, I would go farther as to explicitly randomize it so that users don't rely on it 16:16 < jeremyrubin> Go took this approach with range iterators, they are randomized 16:16 < jeremyrubin> even though the underlying container was ordered 16:17 < jeremyrubin> Before Go 1, when a map was not changed, the runtime returned the keys in the same order when you iterated over its keys/entries multiple times. Note that this order could have changed if the map was modified as the implementation might needed to do a rehash to accommodate more entries. People started to rely on the same iteration order (when map was not changed), so starting with Go 1 the runtime randomizies map iteration order 16:17 < jeremyrubin> on purpose to get the attention of the developers that the order is not defined and can't be relied on. 16:17 < jeremyrubin> from https://blog.golang.org/maps 16:18 < andytoshi> go made many design decisions based on very low expectations of their developers, and the result is a very verbose and inflexible language 16:19 < andytoshi> rust-miniscript takes the opposite design philosophy 16:19 < andytoshi> but 16:19 < andytoshi> in fact, our use of HashMap *does* randomize the output 16:19 < andytoshi> :) 16:28 < jeremyrubin> funny enough I actually think (when I reviewed) you do want a BTreeMap because you do a scan through all keys to find things higher/lower valued 16:28 < jeremyrubin> but I didn't implement those changed 16:30 < sanket1729> CompilationKeys are not completely ordered, but partially ordered. 16:31 < sanket1729> I guess a BTreemap would still require a scan 16:32 < jeremyrubin> CompilationKeys are Ord after my PR 16:33 < jeremyrubin> and you can probably implement a custom Ord so that dissat_prob is the primary key 16:33 < jeremyrubin> Or some other properties you put in I guess? 16:34 < jeremyrubin> Not sure how useful this would be was just something that occured to me but seemed to be more trouble than worth 16:37 < sanket1729> The problem is fundamentally not all compilations are comparable. When inserting a new one, we need to delete all compilations that are worse than it, (here is worse is partial ord). 16:37 < sanket1729> I guess Trie like thing would be the best 16:38 < sanket1729> I guess what I am saying is that even if we implement Ord, it is not useful for efficient operations. 16:39 < jeremyrubin> I guess another way of saying it is that O(worse) == O(all) 16:39 < jeremyrubin> so even if you can skip O(all - worse) entries, it's not a huge help 16:40 < sanket1729> Yup, exactly 16:41 < sanket1729> I guess this is third time someone is confused with the desired usage for policy compiler. Maybe something we should clarify in readme 16:41 < sanket1729> We had a issues someone relying determinism before too. 16:42 < jeremyrubin> I'm doing more digging 16:42 < jeremyrubin> It does seem that Miniscript is OK to be treated and expected to be a mapping? 16:42 < jeremyrubin> https://github.com/rust-bitcoin/rust-miniscript/issues/39#issuecomment-524964451 16:43 < jeremyrubin> I'm OK with that, I only reached to Policy because it's a huge pain in the ass to emit valid miniscript (non-optimized) because of the inference rules around when and how you need to wrap stuff for valid compositions 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 21:08 -!- Netsplit *.net <-> *.split quits: michaelfolkson, sanket1729, harding, shesek, midnight, instagibbs, jeremyrubin, helo, achow101, schmidty, (+22 more, use /NETSPLIT to show all of them) 21:13 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined ##miniscript 21:13 -!- harding [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has joined ##miniscript 21:13 -!- helo [~helo@unaffiliated/helo] has joined ##miniscript 21:13 -!- felixweis [sid154231@gateway/web/irccloud.com/x-rwtspefaioxloplv] has joined ##miniscript 21:13 -!- hugohn [sid304114@gateway/web/irccloud.com/x-ybcpgnhejhwlosqh] has joined ##miniscript 21:13 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript 21:13 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined ##miniscript 21:13 -!- michaelfolkson [~michaelfo@2a03:b0c0:1:e0::23d:d001] has joined ##miniscript 21:13 -!- Ed0 [~edouard@137.ip-193-70-113.eu] has joined ##miniscript 21:13 -!- grubles [~blockhash@unaffiliated/grubles] has joined ##miniscript 21:13 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##miniscript 21:13 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##miniscript 21:13 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 21:13 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has joined ##miniscript 21:13 -!- sgeisler [sid356034@gateway/web/irccloud.com/x-ttewmwdpghvewxca] has joined ##miniscript 21:13 -!- schmidty [sid297174@gateway/web/irccloud.com/x-ckqifnzpczeptffn] has joined ##miniscript 21:13 -!- Aleru [sid403553@gateway/web/irccloud.com/x-bzlawewlmjbhxtqv] has joined ##miniscript 21:13 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript 21:13 -!- jeremyrubin [~jr@2601:645:c200:f539:21b6:bf4:fe1d:6ab9] has joined ##miniscript 21:13 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##miniscript 21:13 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined ##miniscript 21:13 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined ##miniscript 21:13 -!- digi_james [sid281632@gateway/web/irccloud.com/x-acapbubtjyrfcjrf] has joined ##miniscript 21:13 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-siipwwkhxjcfolyk] has joined ##miniscript 21:13 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##miniscript 21:13 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has joined ##miniscript 21:13 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 21:13 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-otyqznegmsqkmiol] has joined ##miniscript 21:13 -!- aj [aj@cerulean.erisian.com.au] has joined ##miniscript 21:14 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##miniscript 21:14 -!- jnewbery [~john@164.90.178.190] has joined ##miniscript 21:15 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-sofhgbgipqnwccsq] has joined ##miniscript 21:16 -!- digi_james [sid281632@gateway/web/irccloud.com/x-acapbubtjyrfcjrf] has quit [Ping timeout: 245 seconds] 21:17 -!- digi_james [sid281632@gateway/web/irccloud.com/x-qxgppfsjpuhvoxcs] has joined ##miniscript 23:34 -!- Davterra [~tralfaz@104.200.129.62] has joined ##miniscript 23:34 -!- Davterra [~tralfaz@104.200.129.62] has left ##miniscript []