--- Day changed Tue Jul 31 2018
03:57 < dongcarl> andytoshi: where is this needed? RPC of some sort?
12:30 < andytoshi> dongcarl: yes
12:31 < andytoshi> dongcarl: i've gotten rust-bitcoin down to essentially one external dep, and then everything HTTP-related pulls in dozens of fast-moving packages that are supposed to be handling untrusted data but are being written by web developers
12:32 < andytoshi> for liquid i think we can transition to only using bitcoin p2p, which rust-bitcoin can handle, but in general this is not a good situation because anyone trying to do a bitcoin app that has a wallet (and doesn't want to write their own wallet) has to talk jsonrpc or rest
16:01 < BlueMatt> andytoshi: well obviously whatever we use for jsonrpc should be a wholly separate crate
16:01 < BlueMatt> and will probably end up relying on serde_json, which also has a deep dep tree
16:02 < BlueMatt> but, I dunno, using hyper and tokio and serde_json seems to work ok for me, I just wouldnt recommend doing it in production
16:06 < BlueMatt> andytoshi: sorry, I'll try to get review most of the stuff later this week or next week
16:06 < BlueMatt> dont really have time today
16:14 < andytoshi> BlueMatt: no worries, thanks for reviewing some of it
16:15 < andytoshi> and sure, jsonrpc is a wholly separate crate (and it's not even under rust-bitcoin because the dependency story is so bad right now, and it doesn't compile on 1.14)
16:15 < andytoshi> but in production, we need to use JSONRPC somehow, and currently our only options are to use the current thing (old hyper, eek) or to use hyper and tokio
16:15 < andytoshi> `strason` can replace `serde_json` btw
16:18 < andytoshi> though i'm likely to switch over to serde_json, its dep tree isn't too bad (only 3: itoa, dtoa and serde)
16:18 < andytoshi> so the only reason to use strason right now is that strason works on 1.14 .... but if i can't get any http clients to work on 1.14, i'll have to have a higher compiler requirement for jsonrpc, then might as well use serde_json
16:28 < BlueMatt> yea, I've generally been building user-facing applications with higher requirements than 1.14 (planning on requiring debian buster when its released next year) and library stuff requiring something older
16:44 < andytoshi> it's interesting how serde_json does arbitrary precision without unsafety ... it serializes string-represented numbers as structs with the name "$__serde_private_Number" and its own serializer recognizes such structs and knows to serialize them as numbers
16:47 < andytoshi> actually the only difference really is that they don't bother detecting their own serializer (that's where my unsafe code comes in). they just serialize this weird hacky struct and if a serializer doesn't recognize it, they'll output the struct
20:46 < dongcarl> Trying to write the fuzz tests here... I think for fuzz_targets, I just cp a file for one of the other modules and modify accordingly... But I'm not sure about how the hfuzz_input's work?
20:48 < andytoshi> you can leave the inputs alone
20:48 < dongcarl> So I don't need to create an input directory? Or I just copy an existing one?
20:49 < dongcarl> Kinda confused about their purpose
20:51 < andytoshi> just ignore it, if you leave it empty (or nonexistent) the fuzzer will create its own starting points
20:51 < dongcarl> Cool
20:52 < andytoshi> but if you have a reason to start with some specific seed, you can use the input directories to do that
21:27 < dongcarl> Fuzzing done for PSBT, still need documentation and better error messages. Anything else I would need?
21:58 < andytoshi> i can't think of anything. i'll try to get your stuff in before i break too much, which i'm planning to do over the next week or two
21:59 -!- sgeisler [~quassel@x8d1ee20a.agdsn.tu-dresden.de] has joined #rust-bitcoin
22:04 < dongcarl> andytoshi: achow told me today that there's something called a "Solver" in core that can extract information from scripts if they detect that it is of one form or another (the script hash from a P2SH, let's say). This would actually be very helpful for helper functions I wanna add to PSBT so users can dump their txs, redeem_scripts, witness_scripts, hd_keypaths, and the like to this function and it
22:04 < dongcarl> would insert them into the right PSBT maps...
22:05 < dongcarl> Do you think writing something like a "Solver" would be uesful in rust-bitcoin? Thinking of opening a new PR
22:05 < dongcarl> (I might be using the wrong terminology but just something that extracts information from scripts it knows about
22:12 < andytoshi> i do not want a solver in rust-bitcoin :)
22:13 < andytoshi> it depends on having a script interpreter
22:13 < andytoshi> well, no, if you have highly structured script templates you can get away with not really understanding script
22:14 < andytoshi> but i think if you're doing stuff with specific script templates it's better to do it outside of rust-bitcoin
22:14 < andytoshi> because otherwise you get into situations like with the `contracthash` module (which i want to split out of rust-bitcoin) where you have a bunch of special-purpose code that people have a hard time forking independently of rust-bitcoin
22:17 < dongcarl> Hmmm... Not sure I'm understanding... I'm only talking about an extension of the is_p2* functions for Script, whereby it would, instead of a bool, output a struct with the encapsulated information (pubkey, script, and such) of the script
22:19 < andytoshi> that would be great, yeah, though those only work for scriptpubkeys
22:19 < dongcarl> like enum ScriptPubKeyInfo { P2SH { script: Script}, P2PKH { pubkey_hash: ...}, ...}
22:19 < andytoshi> which are much simpler than scriptsigs or redeem scripts ... in particular none of them have multisig info
22:19 < andytoshi> yeah, that's fine
22:19 < dongcarl> Cool cool
22:19 < andytoshi> but it's nowhere near what Solver does :)
22:19 < dongcarl> Yeah haha I'm just using the wrong terminology
22:21 < sgeisler> this ScriptPubKeyInfo enum and the encapsulated structs would be useful for lightning-invoice too (for fallback addresses, https://github.com/rust-bitcoin/rust-lightning-invoice/blob/master/src/lib.rs#L120)
22:22 < dongcarl> Okay, sounds like this would make people's lives easier
22:22 < dongcarl> Will do
22:22 < dongcarl> And thanks for everyone's patience
22:26 < andytoshi> thanks for contributing!
23:12 < ariard42> a script disassembler seems a better terminology, isn't it ? Something like objdump -D or -j but for Script :)
23:16 < andytoshi> you can do &script[..] to disassemble it ;)
23:23 < ariard42> Ah good to know!