--- Log opened Tue Oct 26 00:00:14 2021
07:27 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has joined ##miniscript
07:41 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has joined ##miniscript
07:43 < darosior> It was reported in #bitcoin-wizards that `or(thresh(2,pk(A),pk(B)), and(pk(A),after(42)))` compiles on the website although it contains duplicated keys
07:45 <@sipa> the C++ code doesn't check for duplicate keys, indeed
07:49 <@sipa> It probably should, at least for non-malleability analysis.
08:01 < darosior> If we want to do this in ComputeType() to not set "m" in this case, then it would need to be passed the actual nodes not their types
09:16 -!- gene [~gene@gateway/tor-sasl/gene] has joined ##miniscript
10:20 -!- amanr [~aman.rojj@122.161.64.187] has joined ##miniscript
10:20 -!- amanr [~aman.rojj@122.161.64.187] has quit [Client Quit]
11:14 -!- meshcollider [meshcollid@user/meshcollider] has quit [Remote host closed the connection]
11:17 -!- willcl_ark [~quassel@user/willcl-ark/x-8282106] has joined ##miniscript
11:35 -!- meshcollider [meshcollid@jujube.ircnow.org] has joined ##miniscript
13:16 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has joined ##miniscript
13:17 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has quit [Remote host closed the connection]
15:45 < jeremyrubin> darosior the rust code doesn't actually check for repeated keys either (translate {A: 1, B:1} with and(pk(A), pk(B))) in some circumstances
15:46 < jeremyrubin> sipa wdyt about adding codesep support to miniscript
15:48 <@sipa> jeremyrubin: do you have a concrete suggestion?
15:48 <@sipa> conceptually, sure, if there is a use case and a clean way for integrating it
17:15 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
21:05 < jeremyrubin> sipa the point would be more or less "if repeated keys detected, add codeseps"
21:06 < jeremyrubin> and then you eliminate the malleability issue and instead turn it into an efficiency thing 
21:06 <@sipa> just don't repeat keys then :p
21:06 <@sipa> that's even cheaper
21:07 <@sipa> and key generation is trivial
21:07 <@sipa> codeseps aren't sufficient to avoid the issues repeated keys cause
21:07 < jeremyrubin> well let me put it to you then, why does codesep exist in Taproot script at all?
21:07 <@sipa> in general
21:08 <@sipa> good question; i think the answer is: to not remove existing functionality
21:08 < jeremyrubin> what other issue is there?
21:08 < jeremyrubin> i thought it was just and(pk(A), pk(A)) can be malleated
21:08 <@sipa> well, that's a dumb example :p
21:09 < jeremyrubin> "minimum reproduction of the issue"
21:09 <@sipa> but yes, that's the issue, but if you have malleability arising from multiple if/else branches simultaneously, codeseps aren't sufficient
21:10 < jeremyrubin> ah, but it would be any repetition i think, not just within a branch?
21:10 < jeremyrubin> E.g., OR(PK(A), PK(A)) you'd still generate a codesep for
21:11 <@sipa> that you should just replace with pk(A), if you're going to make such modifications
21:11 < jeremyrubin> maybe in policy
21:11 <@sipa> we're talking about policy, i assume?
21:11 < jeremyrubin> but i think for miniscript it should be able to have an underlying script representing such things...
21:11 <@sipa> miniscript itself needs to be roundtrippable
21:12 <@sipa> ah, yes, i agree
21:12 <@sipa> do you understand what i mean by multiple parallel if/else branches?
21:12 < jeremyrubin> not really
21:12 < jeremyrubin> script is single threaded
21:12  * jeremyrubin is obtuse
21:13 <@sipa> haha
21:13 <@sipa> miniscript isn't ;)
21:13 <@sipa> but let me try to give an example
21:13 < jeremyrubin> as in compilation can be parallelized?
21:14 <@sipa> no i mean, miniscript isn't executed, it's a language to describe scripts; it has no operational semantics
21:14 <@sipa> you can think of it as a circuit too if you like, that does everything at once
21:14 <@sipa> but this is besides the point
21:14 < jeremyrubin> ah that's fair. let me propose this to you as an example of something that would make me Very Happy
21:15 < jeremyrubin> we add 2 new keytypes with 1st class support in Ms, a CodeSepKey and a HDKey
21:15 <@sipa> and(or(pk(A),pk(B)),or(pk(C),pk(D)),or(pk(D),pk(A)))
21:15 <@sipa> (think of this as miniscript, not policy, with the necessary wrappers to make it typecheck)
21:15 <@sipa> and with or()'s that are or_i's
21:16 <@sipa> you have 8 combinations paths through the branches
21:16 <@sipa> actually, think of them as c:or_i(pk(A),pk(B) etc
21:17 <@sipa> so the checksig is outside the branch
21:17 <@sipa> oh nvm, codesep would work here
21:17 < jeremyrubin> HDKeys, if included >1 time, derive a new unique key per instances using public derivation. Codesep keys just generate a codesep where included. Thus Miniscript stays 'pure' about describing what you wanted, but policy can do the job of translating normal keys to codesep keys and doing the repetition checks.
21:17 <@sipa> yuck, layer violation :p
21:18 < jeremyrubin> As far as "why not repeat", there are certain optimizations you cannot do if you force folks to generate unique keys for polocy
21:18 <@sipa> how so?
21:18 < jeremyrubin> E.g., consider something that is like this: or(multi(2, [A,B,C]), and(Older(10), A))
21:19 <@sipa> miniscript compiler doesn't do any common subexpression elimination
21:19 <@sipa> so if you write a key multiple times in the policy, it'll appear multiple times in miniscript
21:19 < jeremyrubin> (policy)
21:20 <@sipa> you should just replace A with A' and you're good, i think, in this case
21:20 < jeremyrubin> i don't think that's great
21:20 <@sipa> why not?
21:20 <@sipa> more private too
21:21 < jeremyrubin> well policy should allow repeated keys because policy should, under taproot, try to expand a bunch of the possibilities into unique clauses
21:22 <@sipa> that's fair
21:22 <@sipa> but nothing is lost in that context if you replace the key, either
21:22 < jeremyrubin> actuall it is
21:22 < jeremyrubin> you can't optimize the same in certain cases
21:22 < jeremyrubin> since you don't know that A and A' are known by the same signer
21:23 <@sipa> how would that let you optimize?
21:23 <@sipa> and optimize what?
21:23 < jeremyrubin> e.g., consider or(multi(2, [A,B,C]), and(Older(10), A) v.s. or(multi(2, [A,B,C]), and(Older(10), D)
21:23 < jeremyrubin> err maybe that's not the best example
21:23 < jeremyrubin> 1 sec
21:26 <@sipa> i think i see it
21:26 -!- meshcollider [meshcollid@jujube.ircnow.org] has quit [Changing host]
21:26 -!- meshcollider [meshcollid@user/meshcollider] has joined ##miniscript
21:27 <@sipa> and(or(2,A,B,C),or(1,C,D)) for example; a potential compiler could map each of the 6 paths to separate script leaves
21:27 <@sipa> and the ones which involve two Cs could "deduplicate" them
21:28 < jeremyrubin> yes i think that's a good example
21:28 <@sipa> then again, if you're using musig based aggregation, it doesn't hurt to have a key twice for anything on-chain
21:28 < jeremyrubin> and there might even be cases where certain times you can deduplicate and then certain times you cannot
21:28 < jeremyrubin> but i'm less sure of that
21:30 < jeremyrubin> in any case, if i had to sum up my feeling it's that from a policy PoV we should allow dups since in many cases it's the best way to express the logic, and then i think there are cases where you can't do musig or whatever and then might need a codesep
21:30 < jeremyrubin> and then that generally solves the 'no repeated key' issue since we at least have a way to make a valid thing with the same key twice. hopefully you don't write that miniscript by hand or otherwise avoid it if you can, but in some things it does come up
21:33 < jeremyrubin> anyways not the most critical thing, but it would get rid of a quirk of policy if we could support something like that. I think previously sanket1729_ and i talked about how for taproot anyways if you can 'cleave' the key repetitions anyways it's fine for taproot malleability, this would just be expanding that a bit for corner cases
21:33 < jeremyrubin> gtg for the night :)
23:50 < _aj_> sipa, jeremyrubin: repeated pubkeys might make more sense in the context of anyprevout's "OP_1" that lets you cheaply use the internal pubkey which then might be useful in an or_taproot_mast( and(ipk, pk(ORACLE)), and(ipk, older(100)) ) -- and you're pre-signing txs via musig with the ipk
23:51 < _aj_> (perhaps only relevant with anyprevout still, since everything else commits to the script anyway)
--- Log closed Wed Oct 27 00:00:15 2021