--- Day changed Mon Nov 23 2020
00:19 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
02:34 -!- martindale [ericfabric@gateway/shell/matrix.org/x-hqughkzmhrxeyjgl] has quit [Quit: Bridge terminating on SIGTERM]     
02:42 -!- martindale [ericfabric@gateway/shell/matrix.org/x-ogaatqoiqypshlwd] has joined ##miniscript     
08:44 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript     
09:20 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-vmynyavngcrbrncl] has quit [Quit: ZNC 1.7.5 - https://znc.in]     
09:31 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-yslbdkfqtjhgwjcu] has joined ##miniscript     
11:10 -!- jonatack [~jon@134.19.179.179] has quit [Quit: jonatack]     
11:18 -!- jonatack [~jon@88.124.242.136] has joined ##miniscript     
11:23 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]     
11:23 < andytoshi> sanket1729_: i don't understand, from_der does not seem to be feature gated on fuzztarget
11:23 < sanket1729_> it is
11:24 < andytoshi> lol i see, matt implemented the ffi functions as unimplemented!
11:24 < andytoshi> sigh
11:24 -!- jonatack [~jon@134.19.179.163] has joined ##miniscript     
11:24 < sanket1729_> I can separate that commit. 
11:24 < sanket1729_> from the PR
11:25 < sanket1729_> I think we should remove the feature guard?
11:25 < andytoshi> lemme see if i can figure out how matt uses signatures in fuzztests
11:25 < andytoshi> wdym "remove the feature guard"
11:25 < andytoshi> there are two implementations of secp256k1_ecdsa_signature_parse_der, one with fuzztarget and one not
11:25 < sanket1729_> just have one?
11:25 < andytoshi> do you mean have one call the other? we could do that probably
11:25 < andytoshi> yeah, ok
11:26 < andytoshi> i think that's reasonable
11:26 < sanket1729_> was it done to discourage grinding ?
11:26 < andytoshi> no, matt just disabled the ffi entirely when fuzztarget is on without discriminating at all
11:27 < andytoshi> though given his weird byte-munging of signatures .. i think he has an alternate way of parsing signatures somewhere
11:27 < andytoshi> like, he implemented serialize_der by hand
11:28 < andytoshi> but where  is he getting the sigantures that he's serializing..
11:28 < sanket1729_> I was thinking we could export DummySig under fuzztarget
11:28 < sanket1729_> from rust-miniscript
11:28 < andytoshi> oh lol from _sign
11:28 < andytoshi> i'd really rather not have a fuzztarget feature on any non-crypto libraries
11:29 < andytoshi> or on the crypto ones for that matter. i wish we had a better solution for this
11:29 < andytoshi> btw can i merge the interpreter thing? i added a commit to fix your nit
11:29 < sanket1729_> yes     
11:29 < sanket1729_> I just reviewed
11:29 < andytoshi> dope
11:29 < sanket1729_> it looks good
11:30 < sanket1729_> I can remove the fuzz test commit from satisfy logic
11:31 < sanket1729_> and we can do it later, since it probably requires changes to rust-secp fuzztarget or maybe some brainstorming on how to do other things
11:33 < andytoshi> yeah, let's do that for now
11:33 < andytoshi> and i'll PR to rust-secp to try and fix up the fuzztarget ffi impls so that all the unit tests pass
11:34 < sanket1729_> I can merge 191(interpreter) after CI
11:34 < andytoshi> sure :)
11:35 < andytoshi> nice
11:36 < sanket1729_> rebased and added the PR
11:36 < sanket1729_> we should make a release today. I am working on it
11:36 < andytoshi> great thanks, will review now
11:42 < andytoshi> ok just waiting on ci
11:51 < andytoshi> merged
11:53 < andytoshi> heh i'll need 10-15 minutes to write a changelog... we did a lot
11:56 < andytoshi> eh, i didn't bother with details https://github.com/rust-bitcoin/rust-miniscript/pull/192
12:03 < sanket1729_> oh     
12:03 < sanket1729_> shit I also did one :P
12:03 < sanket1729_> 193     
12:05 < sanket1729_> removing the release commit from my Pr
12:07 < sanket1729_> removed the release commit from my PR. Only have a commit for documentation of sane/insane miniscripts.
12:08 < andytoshi> nice
12:08 < andytoshi> one sentence doesn't flow well, i nitted it
12:09 < sanket1729_> cool
12:09 < sanket1729_> fixing it
12:21 < sanket1729_> CI is passing. andytoshi you can publish a new release
12:23 < andytoshi> kk     
12:23 < andytoshi> publishing
12:25 < andytoshi> done :)
12:25 < andytoshi> ok let's see what's up with rust-bitcoin..
12:32 < sanket1729_> afilini, sgeisler, shesek, justinmoon, darosior, dr-orlovsky, ^ . Just published a new major release. 
12:54 < andytoshi> lol sipa sortedmulti doesn't match bip67?
12:54 < andytoshi> what is the point of bip67 then
12:56 < sipa> it matches bip67
12:56 < sipa> but it works for all keys, not just compressed ones
12:56 < andytoshi> ok, fair
12:57 < andytoshi> i guess, the decision it makes is not a very nice one for libsecp because you need this external piece of data (compressedness) alongside the key
12:58 < andytoshi> also sanket1729_ this is a bug in our impl of sortedmulti
12:58 < sipa> yeah, i can see that's annoying if you treat pubkeys as a parsed type
12:58 < sipa> in bitcoin core pubkeys are just a thin wrapper around a byte array of their serialization
12:59 < sipa> so their natural ordering is the correct one
12:59 < andytoshi> in rust-bitcoin we also keep track of compressedness
12:59 < andytoshi> but libsecp does not :/
13:00 < sipa> yeah, sad distinction between pubkey-from-bitcoin's-perspective and pubkey-the-abstract-concept-of-point-on-a-curve
13:00 < sanket1729_> andytoshi: so how to compare a 64 byte array with a 33 byte one?
13:00 < sipa> 65     
13:01 < andytoshi> sanket1729_: you'll have to zero out a 65 byte array and memcpy the 33 bytes into it
13:01 < andytoshi> or compare them as byte slices
13:02 < andytoshi> you'll also need an explicit branch on the compressedness because the rust-bitcoin "serialize" method (or whatever we call it) allocates heap memory
13:04 < andytoshi> sanket1729_: we should probably PR to rust-bitcoin to impl Ord on the publickey type
13:04 < andytoshi> rather than doing it in rust-miniscript
13:04 < sanket1729_> as in Impl for Ord/PartialOrd on bitcoin::PublicKey?
13:04 < andytoshi> yeah
13:05 < sanket1729_> cool. I can do that. meanwhile, how do we indicate the the sortedmulti does not work correctly for uncompressed keys
13:06 < andytoshi> i think we just quietly fix it in version 4.1
13:07 < andytoshi> and add a note to the changelog
13:07 < sanket1729_> Should two keys(one compressed and uncompressed) be Eq?
13:07 < andytoshi> nope
13:07 < sipa> i hope nobody is actually using rust-bitcoin/miniscript with uncompressed keys
13:07 < andytoshi> lol it's a good question, i assume nobody is
13:08 < sipa> sanket1729_: compressed is (0x02 or 0x03) + ..., uncompressed is 0x04 + ..., so compressed always sorts before uncompressed
13:08 < andytoshi> that's pretty convenient
13:09 < sanket1729_> so, our current implementation is correct?
13:09 < andytoshi> it would be even more convenient if, once you conditioned on having two uncompressed keys, they'd sort correctly by compressed serialization ... but alas
13:09 < sanket1729_> but yeah, we should still do it properly
13:09 < andytoshi> sanket1729_: no
13:09 < sanket1729_> it does .seralize and sorts the vec
13:09 < andytoshi> sanket1729_: our current impl sorts things by their compressed seriaziton
13:09 < andytoshi> it sorts the vec??
13:09 < sanket1729_> yeah
13:09 < andytoshi> i do not remember it allocating memory
13:09 < andytoshi> i     
13:09 < andytoshi> specifically checkde for this
13:10 < sanket1729_> we call .serialize
13:10 < sipa> andytoshi: crazy edge case in that hypothetical... if you have a sortedmulti with both the compressed and uncompressed version of the same key
13:10 < andytoshi> sanket1729_: on the rust-secp key right?
13:10 < sipa> if you treat them as equal, the order is unspecified
13:10 < andytoshi> that serializes in compressed encoding into a 33 byte array
13:10 < sanket1729_> oh, right
13:11 < sipa> so really you could implement sorting of keys by sorting the tuple (!key.uncompressed, key.compressed_serialized)
13:11 < sipa> that even works if you have two keys that only differ by evenness of the Y coordinate
13:12 < andytoshi> i don't think it does
13:12 < sipa> oh     
13:12 < sipa> it doesn'ty
13:12 < andytoshi> because the compressed serialization will sort by the parity of the y coord
13:12 < andytoshi> yeah :(
13:12 < sipa> you're right :(
13:12 < andytoshi> so close..
13:12 < andytoshi> i mean, this is also an edge case..
13:12 < andytoshi> but we ought to do the right thing
13:22 < sanket1729_> Is this the same way for XOnlyKeys?
13:22 < sanket1729_> serialize and compare?
13:22 < sanket1729_> We don't have those yet, but just curious
13:22 < sipa> xonlykeys are much nicer, they're just 32 bytes :)
13:23 < sanket1729_> But how to compare those with other keys
13:23 < sanket1729_> in sortedmulti
13:23 < sipa> they don't
13:23 < andytoshi> but yes - libsecp will not allow you to sort on the internal representation
13:23 < andytoshi> you have to sort first
13:23 < andytoshi> encode*
13:23 < sipa> sanket1729_: they're a completely different data type; there is no place where you'd expect one and it can be compared with another
13:24 < andytoshi> sanket1729_: convienently you cannot mix xonly and old-school keys in bitcoin script
13:24 < sanket1729_> yup, makes senes
13:24 < sipa> but if you so desire, if you convert them to normal compressed pubkeys, things will just work - they'll all be 0x02 + xdata)
13:24 < sanket1729_> we first need to encode to compare
17:10 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]     
18:08 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript     
22:15 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript     
22:15 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
22:15 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript     
22:29 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 264 seconds]     
23:59 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]