--- Log opened Sat Jun 12 00:00:35 2021
02:01 -!- belcher_ is now known as belcher
04:48 -!- roconnor [~roconnor@host-45-58-218-136.dyn.295.ca] has quit [Ping timeout: 272 seconds]
05:18 -!- roconnor [~roconnor@host-184-164-16-124.dyn.295.ca] has joined #secp256k1
06:29 -!- nsh [~lol@5.135.157.17] has joined #secp256k1
11:06 < sebx2a> dr-orlovsky: with taproot locking in being quite certain now we might want to push forward more heavily. Do you need help/review for anything? https://github.com/rust-bitcoin/rust-bitcoin/pull/563/ seems to need doc fixes (broken links, most likely just needs an absolute path)
13:30 < BlueMatt> given two public keys representing the same x/y coordinates, is it safe/supported/correct to compare the 64 byte strings returned by, eg, ec_pubkey_parse?
13:31 < BlueMatt> eg no matter how the two public keys were created, if they are the same x/y, can you compare the 64 bytes?
13:31 < sipa> you mean the secp256k1_pubkey type?
13:31 < BlueMatt> yes
13:32 < sipa> i believe the answer is currently yes, but the serialization isn't stable
13:33 < BlueMatt> damn, then I cant blame andrew for my bug
13:33 < gmaxwell> The type is supposed to be effectively opaque.
13:33 < sipa> note https://github.com/bitcoin-core/secp256k1/pull/850
13:34 < BlueMatt> yes, opaque is fine, i was just making sure that the use of hash(pubkey 64 bytes)+memcmp(pubkey 64 bytes) would result in correct hash-table functionality
13:34 < gmaxwell> also depending on the context... bip340 pubkeys are only 32-bytes, and there may be two different 64-byte keys that get treated as the same bip-340 key. (though thats technally wrong to do)
13:37 < gmaxwell> BlueMatt: the representation is implementation specific and I don't think it's promised to be completely initilized or free of padding, which would make it ill-advised to hash it for a hash table.
13:38 < BlueMatt> hmmmm, good point, is it possible its *currently* not fully initialized or padded?
13:38 < BlueMatt> I guess I can take up with andytosh1 doing a serialize before hashing, but I also currently see issues right now that I'm puzzling through.
13:38 < sipa> in the current code it's effectively an architecture-specific efficient serialization of the X and Y coordinates
13:38 < BlueMatt> not with addrsan, though, sadly
13:39 < sipa> so any function that outputs a secp256k1_pubkey will fully initialize it
13:39 < sipa> (any *succesful* function)
13:39 < BlueMatt> k
13:39 < BlueMatt> definitely not the bug then :)
13:39 < dr-orlovsky> sebx2a: replied in #bitcoin-rust
13:41 < gmaxwell> BlueMatt: in the current code it's effectively just a serialized key except for byteorder.
13:41 < sipa> i think that failed parsing or so even initializes it to an invalid value
13:42 < gmaxwell> yeah, I think at some point I went through and made all the failure cases I could set it to a value that other code would be sure to fail on.
13:42 < gmaxwell> To avoid issues where a failed deserial left an old pubkey in a stack temporary and then a caller that failed to handle the error went on to process something with the wrong pubkey.
13:43 < BlueMatt> nvm, found the bug...there's too many damn layers to this whole thing, makes it hard to think about bug hunting :)
21:07 -!- jesseposner [~jesse@2601:647:0:89:a033:d06b:c178:5c11] has quit [Ping timeout: 252 seconds]
21:33 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
21:37 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 268 seconds]
23:59 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
--- Log closed Sun Jun 13 00:00:25 2021