--- Log opened Fri Nov 12 00:00:30 2021
04:10 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Quit: Bridge terminating on SIGTERM]
04:10 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has quit [Quit: Bridge terminating on SIGTERM]
04:27 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined ##miniscript
04:37 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has joined ##miniscript
04:51 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Quit: Client limit exceeded: 20000]
07:20 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has joined ##miniscript
08:03 -!- AlekosFilini [~afiliniaf@51.15.93.184] has joined ##miniscript
08:03 < AlekosFilini> i'd like to help with the taproot work in rust-miniscript: i'm playing a bit with the code from this pr https://github.com/rust-bitcoin/rust-miniscript/pull/278, specifically i'm working on integrating schnorr keys in `DescriptorPublicKey`
08:03 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined ##miniscript
08:03 < AlekosFilini> i'm trying to come up with a way to ensure ecdsa keys aren't used in taproot descriptors and the only thing i can think of is adding either `ScriptContext` itself or something similar to the `MiniscriptKey` trait
08:05 < AlekosFilini> is there a better/less "invasive" way to do it in your opinion?
08:07 <@sipa> what are "ecdsa" keys? they're all just EC keys
08:08 <@sipa> the only difference is that in tr descriptors you're additionally allowed to use 64-character-hex x-only pubkeys
08:08 -!- gene [~gene@gateway/tor-sasl/gene] has joined ##miniscript
08:08 < AlekosFilini> in rust-bitcoin there are different types for ecdsa and schnorr keys
08:09 <@sipa> oh, ok
08:09 < AlekosFilini> for instance i don't think a ecdsa::PublicKey can parse an x-only pk, and vice-versa
08:09 <@sipa> vice-versa should work
08:09 < sanket1729_> that would be changed to xonly keys and ec keys in the next release
08:10 <@sipa> you can use 66-char hex pubkeys in tr() descriptors e.g. (but when serialized to script, only their 32-byte x-only part is emitted)
08:11 < sanket1729_> AlekosFilini: can you look at test_tapscript_rtt? I think it is already implemented
08:11 <@sipa> also xpubs etc
08:12 < AlekosFilini> sanket1729_: thanks, i'll take a look
08:13 < AlekosFilini> so the idea is to just keep using `bitcoin::PublicKey` everywhere and then depending on the context serialize it differently in the actual scripts?
08:13 <@sipa> (i'm talking about the textual descriptor language, not about whatever internal representation rust-bitcoin is using)
08:15 < AlekosFilini> yes sorry, the question was directed to sanket1729_ specifically
08:17 < sanket1729_> Yes. For DescriptorPublicKey, we would need to parse both bitcoin::PublicKey and XonlyKeys
08:17 < sanket1729_> The serialization is already implemented
08:18 < AlekosFilini> sanket1729_: awesome, that makes sense
08:18 < sanket1729_> All keys in tr() descriptor would be encoded as xonly keys regardless how they were parsed from textual representations
08:21 < AlekosFilini> and if there's an odd pubkey is it rejected or negated (not sure if that's the right term) internally to get the even one?
08:21 < sanket1729_> The first byte is ignored
08:22 < sanket1729_> In particular, I think what is missing in 1) update for DescriptorPublicKey::from_str to parse xonly keys and 2) BIP32 derivation of xonly keys. 
08:42 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
09:01 -!- gene [~gene@gateway/tor-sasl/gene] has joined ##miniscript
11:13 < sanket1729_> andytoshi: while in rust review spree. This cannot be merged until a new rust-bitcoin release, but we can still work on addressing the review. https://github.com/rust-bitcoin/rust-miniscript/pull/275
11:43 < andytoshi> yep sure
11:49 -!- AlekosFilini [~afiliniaf@51.15.93.184] has quit [Quit: Bridge terminating on SIGTERM]
11:49 -!- enick_103 [~afilini-m@2001:bc8:1828:245::2] has quit [Quit: Bridge terminating on SIGTERM]
11:50 -!- enick_60 [~afilini-m@51.15.93.184] has joined ##miniscript
11:56 < andytoshi> lol sanket1729_ it already needs updating as rust-bitcoin master has changed 
11:56 < andytoshi> (but i will read the code regardless)
12:04 < andytoshi> did we agree to use OP_NUMEQUAL for multi_a? i like it, it's a new opcode and makes parsing very easy
12:04 < andytoshi> but NUMEQUAL does not appear in my IRC logs so i wanted to draw attention to it here
12:05 <@sipa> any reason not to?
12:07 < andytoshi> nope, i think it's good
12:11 < sanket1729_> I got that from https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_ref-5-0
12:12 < andytoshi> oh, nice
12:14 < sanket1729_> I remember discussing it somewhere, but I don't know where :( 
12:15 < andytoshi> maybe waaay back when we were designing checksigadd?
13:25 < jeremyrubin> Does checksigadd support weighted keys?
13:28 <@sipa> no
14:18 < _aj_> "CHECKSIG <w> MUL ADD" for that?
14:18 <@sipa> right
14:19 <@sipa> if all the weights form a multiplication chain you can use CSA
14:20 <@sipa> e.g. k1 CHECKSIG k2 CHECKSIGADD w1 MUL k3 CHECKSIGADD k4 CHECKSIGADD w2 MUL k5 CHECKSIGADD k6 CHECKSIGADD v NUMEQUAL
14:20 <@sipa> tests k1 and k2 with weight w1*w2
14:20 <@sipa> and k3 and k4 with weight w2
14:20 <@sipa> and k5 and k6 with weight 1
14:24 < jeremyrubin> that'd be cool to support in ms
14:24 < jeremyrubin> altho i guess you can do that by adding the same key >1 times in musig / having >1 key per person
14:25 < _aj_> 0 {k1 CHECKSIG k2 CHECKSIGADD .. w MUL ADD} v NUMEQUAL -- isn't much more complex if you want independent groups of weights
14:26 < jeremyrubin> ah right this is why i was going to ask about numequal
14:26 < jeremyrubin> we should make it gtequal
14:27 < jeremyrubin> if weights are involved
14:27 < _aj_> sure
14:27 <@sipa> well for multi_a it doesn't matter, unless it's extended to support weights
14:28 < jeremyrubin> altho
14:28 < jeremyrubin> numequal also works
14:28 < jeremyrubin> if you have a combinatorial thing
14:28 < jeremyrubin> to compute all possible weightings
14:28 < jeremyrubin> possible minimally exceeding threshold weightings
14:29 <@sipa> for something with weights, i think gtequal is probably more natural as a policy
14:29 < jeremyrubin> but this is also problematic
14:29 < jeremyrubin> yeah
14:29 < jeremyrubin> the issue being extra witness data
14:29 < jeremyrubin> numequal guarantees "minimal"
14:30 <@sipa> that's a good point
14:30 <@sipa> you get trivial malleability with gtequal
14:30 < jeremyrubin> so you kinda want to expand the weighted multi to all minimal satisfactions
14:30 < jeremyrubin> or something
14:31 < jeremyrubin> ¯\_(ツ)_/¯ 
14:31 < jeremyrubin> i guess strictly speaking there's no point in having multi weighted in script since they can always be a multi_a in miniscript?
14:32 <@sipa> ?
14:32 < jeremyrubin> uh
14:32 < jeremyrubin> handle it at policy layer
14:32 < jeremyrubin> is what i mean
14:33 <@sipa> i think they're distinct policies
14:33 <@sipa> and distinct miniscripts
14:34 < jeremyrubin> e.g., policy multi(A w 2, B w 1, C w 1, D w 1, thresh= 3) could just be expanded to OR(AB, BCD, AC, AD)? 
14:34 < jeremyrubin> how complex can a weighted multi be computationally?
14:34 <@sipa> not every weighted threshold can be translated to an efficient and/or tree
14:35 < jeremyrubin> gotcha
14:35 < jeremyrubin> i thought it might be able to be
14:35 <@sipa> especially not without duplicating subexpressiosn
14:35 <@sipa> which would introduce malleabiltiy again
14:35 < jeremyrubin> presumably in TR that's more OK since you'd be making unique branches
14:35 < jeremyrubin> (i was only thinking of weighted multi for TR)
14:35 <@sipa> that's still an open question - it's not always optimal to map policy choices to separate scripts
14:36 <@sipa> but i guess if you restrict the compilation to always expanding fully, then yes, that's pretty easy
14:39 < jeremyrubin> it does seem like there's not a tidy way to non malleably represent these weighted circuits that don't expand 
14:40 < jeremyrubin> i don't know if that sentence made sense
14:50 < _aj_> would it be better to spend time making the mempool able to just validate and accept (and potentially propogate) a better witness for an existing txid so that witness malleability is just less of an issue?
14:53 < _aj_> (pr 19645 tries that)
14:56 < jeremyrubin> _aj_ i think not personally, since witness malleability can cut multiple ways if not careful. E.g., suppose i have a script (stupid!!!) that's like OP_DROP <PK> CHECKSIG and you supply 0 byte sentinel to be dropped, then a malicious relayer could change it to 520 bytes and that would be bad. Further, a malcious relayer might also get a bunch of
14:56 < jeremyrubin> 'free relay' by sending a bad txn first and then upgrading it repeatedly (e.g., start at 520 then 519 518...)
14:56 < jeremyrubin> this is a contrived example of course
15:02 < _aj_> jeremyrubin: "potentially propogate" ==> if it improves by the DEFAULT_INCREMENTAL_RELAY_FEE rate, so i don't think that's a big deal
15:02 < _aj_> jeremyrubin: maybe you don't even update your mempool entry if it doesn't do that, so that you don't lose compact block relay benefits
15:03 < _aj_> (i kind of think it'd be nifty if you could replace a script path witness with a key path witness if the missing signers showed up before your tx confirmed...)
17:14 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Ping timeout: 276 seconds]
17:14 -!- elsirion_ [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript
19:21 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has quit [Remote host closed the connection]
19:46 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has joined ##miniscript
22:43 -!- roconnor [~roconnor@host-45-58-217-8.dyn.295.ca] has quit [Remote host closed the connection]
23:53 -!- kallewoof [~quassel@user/kallewoof] has quit [Ping timeout: 268 seconds]
--- Log closed Sat Nov 13 00:00:31 2021