--- Day changed Sun Aug 12 2018 02:39 < dongcarl> andytoshi: Hey you got an updated version of descriptor? I'll write up the parser if you think it's not in too much flux 02:50 < andytoshi> dongcarl: sure, one sec 02:50 < andytoshi> it hasn't changed really since i posted, but i'll re-up the whole descriptor.rs 02:51 < andytoshi> https://0bin.net/paste/8me4XpMaXwgO5Asl#c2yUrrMcdVBveKHbdzJFLQQbeKvviFeuyejfEcWZMyk 02:51 < andytoshi> this should build, though the unit tests won't because you don't have ParseTree::compile 02:51 < andytoshi> also you're welcome to rename Key and KeyHash to Pk and Pkh to match sipa's gist 03:16 < dongcarl> andytoshi: Cool. Do you think you'll put up a repo soon? 12:04 < andytoshi> dongcarl: yeah, maybe today. i want to play around with your psbt code using the parser/serializer first and make sure that the api makes sense 12:04 < andytoshi> then i'll start pulling stuff out of rust-bitcoin and move to a new repo, so we can PR and move quickly 12:52 < andytoshi> i just need to put thresholds back into the language (and back into the descriptors) 14:38 < andytoshi> dongcarl: can you use ConsensusEncodable/Decodable instead of new PSBT serialization traits? 16:10 < andytoshi> musing on whether PSBT belongs in the script descriptor crate or not 16:10 < andytoshi> probably the combiner and finalizer roles do ... creator i'm not sure about ... and signer is really gonna be application-specific 16:11 < andytoshi> i guess the data structures and stuff belong in rust-bitcoin; the script descriptor crate can implement a combiner and finalizer that uses descriptors 16:11 < andytoshi> and Signer can be done by whatever wallet crates there are 19:23 < andytoshi> i asked sipa about adding p2c to the descriptor language as a standard thing. he thinks it's a good idea 19:23 < andytoshi> and that it would also be nice to have a psbt extension for it 19:24 < andytoshi> dongcarl: also, i found a couple bugs in the rust-bitocin psbt pr 22:02 < dongcarl> andytoshi: Looking at them now... 22:03 < dongcarl> andytoshi: >p2c great! 22:06 < dongcarl> andytoshi: I used to use ConsensusEncodable/Decodable, but there are some things that don't work: 1. Scripts are ConsensusEncoded/Decoded with a VarInt at the beginning, but not so in PSBT (as there is already a VarInt indicating the value's length) 2. Some types only make sense to serialize/deserialize in the context of PSBT as I asked about before, like `SigHashType` or `(Fingerprint, 22:06 < dongcarl> Vec)` 22:08 < dongcarl> By defining a macro to implement PSBTSerialize/Deserialize for those that do work like ConsensusEncodable/Decoable, and providing custom implementations for the rest, it handles the exceptions while still exposing a consistent API to callers 22:09 < andytoshi> right, i understand 22:09 < andytoshi> ok that's fine 22:10 < dongcarl> Just to be clear, we're making psbt::serialize::PsbtSerialize into psbt::serialize::Serialize exposed as psbt::Serialize? 22:11 < dongcarl> I kinda like that actually 22:11 < dongcarl> Cuz for people to use it they must've typed in the path in a `use` and know what they're importing... 22:13 < andytoshi> yeah 22:13 < andytoshi> right exactly 22:16 < dongcarl> andytoshi: Seems like I've been writing a lot of the same code in places... So wondering if I should add a function `pub fn derive(&self, secp: Secp256k1, cnums: Vec) -> Result` to ExtendedPubKey 22:17 < andytoshi> cnums should be a `&[ChildNumber]`, and yeah, sure 22:17 < dongcarl> Cool, is the name derive good? 22:18 < andytoshi> should probably be `derive_public` or something 22:18 < andytoshi> but yeah, anything is fine 22:28 < andytoshi> dongcarl: BTW i think you should change your fuzzer to try re-serializing anything it can deserialize, and checking that you get the same result 22:29 < andytoshi> because i'm going to go that and separately report every issue it finds :P 22:29 < andytoshi> this is how i noticed that it'd accept nontrivial "unsigned tx" keys 22:48 < dongcarl> andytoshi: gotcha! 22:53 < dongcarl> Should I stick to the convention in ExtendedPrivKey? It has a from_path(secp: &Secp256k1, master: &ExtendedPrivKey, path: &[ChildNumber]) -> Result 22:53 < dongcarl> I think instead of `master: &ExtendedPrivKey` it should be `&self` 23:04 < andytoshi> ah, yep 23:04 < andytoshi> you can change it for `ExtendedPrivKey` too 23:06 < dongcarl> :okhand: 23:35 < dongcarl> Added https://github.com/bitcoin/bips/blob/941fb162d8cf649ea3a0a85011ebac5883f82819/bip-0032.mediawiki#test-vector-3 23:35 < dongcarl> Seems like our BIP32 implementation has this fault 23:35 < dongcarl> Going to investigate 23:36 < andytoshi> cool, thanks for noticing 23:36 < andytoshi> though glancing at this issue, it would surprise me 23:37 < andytoshi> there are no "leading zeroes" in private keys, they're 32-byte objects that are never treated as numbers by rust-bitcoin 23:37 < andytoshi> and the batshit behaviour of base58 wrt leading zeroes (which is maybe unrelated?) has been thoroughly tested in rust-bitcoin 23:50 < andytoshi> dongcarl: that test vector passes in rust-bitcoin for me 23:51 < andytoshi> both before and after the recent changes to the ChildNumber API 23:52 < dongcarl> andytoshi: hmmm 23:52 < andytoshi> and i also skimmed the code for anywhere that "leading zeros" might make sense and didn't find anywhere. this is the kinda thing that rust's type system makes very hard to fuck up 23:53 < andytoshi> did you reverse the priv and pub in your copy of the test case? they're in reverse order in the BIP and in my test function 23:53 < andytoshi> (idk why i did that) 23:53 < dongcarl> andytoshi: I did... I added more things to test_path though, could be that 23:53 < dongcarl> I'll do a trace 23:54 < andytoshi> ok, cool, thanks 23:54 < andytoshi> in general i wonder if theer are other libraries we could fuzz against 23:55 < dongcarl> Lol... I accidentally added a space at the end of the seed... 23:55 < dongcarl> Anyways we're good 23:55 < andytoshi> lol excellent 23:56 < dongcarl> andytoshi: When I actually have time I was planning on writing a prolog program that generates test vectors for bitcoin serialization... It's quite good for serialization/deserialization as the serializer is automatically implemented if you implement the deserializer (prolog magic) 23:56 < dongcarl> One day... 23:57 < andytoshi> heh one day