--- Day changed Thu Jul 23 2020 02:14 -!- jonatack [~jon@82.102.27.195] has joined ##miniscript 03:29 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 03:34 -!- jonatack [~jon@82.102.27.195] has quit [Ping timeout: 240 seconds] 03:35 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined ##miniscript 03:46 -!- jeremyrubin [~jr@2601:645:c200:f539:c03f:40d9:1aa8:e444] has quit [Ping timeout: 260 seconds] 04:06 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 04:06 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript 05:13 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 240 seconds] 06:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript 06:38 -!- shesek [~shesek@5.22.128.126] has quit [Changing host] 06:38 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript 07:54 -!- Davterra [~Davterra@37.120.208.253] has joined ##miniscript 09:24 -!- jeremyrubin [~jr@2601:645:c200:f539:c03f:40d9:1aa8:e444] has joined ##miniscript 09:48 < darosior> sanket1729: re "we pick sub-compilations for children optimally. All pk() are mapped to pkh()" : how is pkh() more optimal than pk() ? 09:49 < jeremyrubin> I think probably has to do with a stack size vs script size tradeofff? 09:50 < sanket1729> darosior: Because in cases where the child is not satisfied, your witness script is only 20 bytes hash + few other bytes compare to 33 bytes pk 09:50 < jeremyrubin> ah 09:50 < darosior> Ah it's actually because of the disatisfaction cost ? 09:50 < darosior> Thanks 09:51 < jeremyrubin> not quite dissatisfaction cost, seems more it's the static script length for keys unused 09:51 < jeremyrubin> dissatisfaction cost for pk (nothing) is cheaper than pkh (1 byte) 09:52 < jeremyrubin> maybe I'm mistaken but dissat cost is the variable amount 09:53 < sanket1729> yes, it is related to static script len 09:53 < darosior> Ok, thanks! 09:57 < sanket1729> jeremyrubin: the dissat cost of pk() is 1 byte, empty witness and dissat cost for pkh would be 35 bytes because we provide the public key. However, in more cases the compiler avoids this dissat cost by wrapping pkh around unlikely making the dissat cost 1 byte. 09:58 < jeremyrubin> oh? Why not make pkh dissat by something not length 0x20? 09:58 < jeremyrubin> or 0x21 i guess 09:59 < jeremyrubin> Ah I guess because pkh results in a pk type 09:59 < jeremyrubin> rather than a bool type.. 10:00 < sipa> pkh is DUP HASH160 EQUALVERIFY CHECKSIG 10:00 < sipa> to dissatisfy it you still need to provide the correct pubkey; just not the signature 10:01 < sipa> so the dissatisfaction cost includes the vbytes spent on that pubkey 10:14 < darosior> Has the inclusion of an analysis of duplicated keys in policy compilers already been discussed (any implem) ? 10:53 < sanket1729> It is difficult to guarantee non-malleability if the scripts has duplicated keys. 10:54 < sanket1729> We can transfer witness from one satisfaction to another. 10:59 < sanket1729> darosior: I saw your issue, my hunch is that it not always possible to convert duplicated keys into an equivalent policy such that the resultant policy only contains one key 10:59 < sipa> i think analysis of duplicate keys would just be "does it have repeated keys? if so, can't say anything about nonmalleability" 11:00 < sanket1729> He is suggesting that in some cases it is possible to convert policy description that has key reuse into another one where there is no key-reuse. 11:00 < sanket1729> See https://github.com/rust-bitcoin/rust-miniscript/issues/115 11:00 < sipa> sure 11:00 < sipa> but not always 11:00 < darosior> Indeed, but could we at least try to optimize in some simple cases similar to the one I mention in the issue ? 11:01 < sipa> but i don't think it's an optimization 11:01 < sipa> you're giving the policy in a degraded equivalent notation 11:02 < sipa> in general, if you have a policy with repeated keys, we'll just fail to compile 11:02 < sipa> (well, or it should at least because keys are repeated and we should detect that) 11:02 < darosior> Why degraded ? It results in a (way more) efficient Script 11:03 < sipa> no no 11:03 < sipa> the original i argue is just an invalid policy 11:03 < sipa> which happens to be equivalent to a valid one 11:03 < darosior> Ah ok 11:03 < sipa> not opposed to doing a source-to-source transformation as a separate tool or something 11:04 < sipa> but proving equivalences across that is going to be hard in general 11:31 < jeremyrubin> sipa: should taproot signatures sign the stack index (or something) to prevent this sort of signature malleability? 11:33 < sipa> jeremyrubin: there is OP_CODESEPARATOR if yiu want that 11:33 < jeremyrubin> Ah right 11:34 < jeremyrubin> i was thinking something still worked for that but couldn't find it in the spec 11:34 < jeremyrubin> isn't the codesep semantic changed somewhere? 11:35 < sipa> the downside is that it may mean you need to know up front which script if/then branches are going to be executed 11:35 < instagibbs> jeremyrubin, it includes the position in sighash 11:35 < instagibbs> rather than changing "scriptCode" 11:35 < sipa> yes, codesep is just literally "remember the last execution codesep position and include it in signature" 11:35 < instagibbs> "codesep_pos" 11:35 < sipa> the old wonky scriptCode effect is gone (as scriptCode is gone too) 11:36 < jeremyrubin> Ah gotcha. Makes sense that it's in 342 now that I think about it 11:36 < jeremyrubin> but it's confusing because 340 and 341 are more the 'signature-y' ones 11:37 < jeremyrubin> it seems that codesep is insufficient for the problem above 11:37 < sipa> my opinion is that you should just not reuse keys 11:37 < sipa> you can always replace it with two different keys from the same party 11:37 < jeremyrubin> because if it's 2 x x 2 checkmultisig, not clear where the codesep can go that prevents malleatitng the 2 x signatures 11:38 < sipa> or you can split it into different leaves 11:38 < jeremyrubin> sipa: or provably non maliciously deterministically tweaked keys. 11:38 < sipa> yes 11:38 < sipa> exactly 11:38 < jeremyrubin> I think the issue would more come up in someone maliciously sending you a script that analyzes to be under your control 11:38 < jeremyrubin> and then you think you're malleation safe 11:39 < jeremyrubin> but because of the repeated key issue, you aren't 11:39 < sipa> "being under your control" is never the right criterion for whether something is a payment to you 11:39 < sipa> it's the right criterion for emergency recovery though 11:43 < jeremyrubin> I'm not sure how to reconcile that with your earlier stated views on how policies should be deployed/used and determinism. If you can't reverse a script to determine under your controllness, and don't have forward determinism, what is the property being used that engenders "under your controllness"? 11:45 < sipa> policy to miniscript happens before script creation 11:45 < sipa> you negotiate a scriptPubKey or sequence of scriptPubKeys to use for your payments, providing each other with necessary information to analyze it 11:46 < sipa> but that analysis is not "is it under my control"; it is "does this policy have the properties i expect" 11:46 < sipa> and then you accept payments to exactly those scriptPubKeys and nothing else 11:47 < jeremyrubin> Gotcha so your plan with miniscript is really that generation is all happening recipient side than sender? 11:48 < sipa> no 11:48 < sipa> in a complex contract there generally isn't one recipient and one sender, just multiple parties 11:48 < jeremyrubin> I was just typing that ;) 11:48 < sipa> ah 11:48 < sipa> but there may be a hierarchy 11:48 < sipa> like you have a 2fa service 11:49 < sipa> that does some 2-of-3 multisig with timelocks and recovery keyd and whatnot 11:49 < sipa> but you want to participate in it with your 2-of-2 hw wallet + phone setup 11:50 < sipa> either the servixe or you generate the descriptors to use 11:50 < sipa> but each should be able to verify that those descriptors match what they expect 11:50 < sipa> like the user can't get rid of the service's keys 11:50 < sipa> and this should be done before any transactions are performed 11:51 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 11:51 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 11:52 < jeremyrubin> I guess concretely if the thresh(k, ...) allows repeated keys then it should not be s or e as it is malleable. 11:53 < jeremyrubin> And I don't think that property is currently analyzable 11:57 < sanket1729> IMO the complexity to add the analysis and change the typing rules for key-reuse is not worth it. Best to avoid it by saying, we don't offer any guarantees if the keys are reused. Would further complicate the non-malleable signing logic. 11:59 < jeremyrubin> i think that's a reasonable choice I just think it needs to be well documented 11:59 < jeremyrubin> or maybe just auto-reject repeated keys 12:34 -!- Davterra [~Davterra@37.120.208.253] has left ##miniscript ["Leaving"] 12:39 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 12:40 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has joined ##miniscript 13:30 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 256 seconds] 14:10 -!- shesek [~shesek@5.22.135.23] has joined ##miniscript 14:12 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 14:14 -!- shesek [~shesek@5.22.135.23] has quit [Ping timeout: 240 seconds] 14:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 14:17 -!- shesek [~shesek@5.22.135.23] has joined ##miniscript 14:22 -!- shesek [~shesek@5.22.135.23] has quit [Ping timeout: 256 seconds] 14:23 -!- shesek [~shesek@5.22.135.23] has joined ##miniscript 14:27 -!- shesek [~shesek@5.22.135.23] has quit [Ping timeout: 240 seconds] 14:31 -!- shesek [~shesek@5.22.135.23] has joined ##miniscript 14:33 -!- shesek [~shesek@5.22.135.23] has quit [Changing host] 14:33 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript 16:00 -!- afk11` is now known as afk11 18:12 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds] 18:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 18:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 18:20 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##miniscript 23:32 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]