--- Day changed Thu Nov 01 2018 02:41 < BlueMatt> dongcarl: not *replace*, augment 02:42 < BlueMatt> gmaxwell: do you happen to know how far along https://github.com/thepowersgang/mrustc is? it claims to be able to compile rustc by transpiling it into C++ (without full borrowcheck support) and then you can recompile it with your new bootstrapped rustc 02:42 < BlueMatt> err, s/do you happen to know how far along/have you tried/ 03:36 < dpc[m]> stevenroose (IRC): Just making sure you've seen https://github.com/jeandudey/rust-bitcoin-rpc/issues/6#issuecomment-432434731 . At least in bitcoin-rpc crate the use of macros seemed largely unnecessary. What I disliked most about them however is that they contained `?` which means the macro was silently early-returning from the calling function, which is very confusing. One great property of Rust is that code flow is 03:36 < dpc[m]> always explicit and obvious. 08:18 < wumpus> agree with regard to bootstrap-ability of rust, though everything considered, modern C/C++ is also going to be a hell of a lot of work to bootstrap from scratch 08:20 < wumpus> in practice cross-compilation is used to support new platforms, whether that's for C or Rust 09:18 < wumpus> whoever writes a Rust compiler (or at least, enough to compile the current compiler eventually) in RISC-V assembly from scratch has my eternal gratitude 10:38 < stevenroose> So apparently the Trezor refuses to sign a tx with an input for which you can't provide the whole utxo tx.. Which kinda messes with the idea of the proof-of-reserves tool to have an invalid input that commits to a random string. 10:39 < stevenroose> s/random/challenge/ 11:36 < stevenroose> andytoshi: no function or associated item named `signing_only` found for type `secp256k1::Secp256k1` in the current scope 11:36 < stevenroose> In the same scope, I can do `new`, `without_caps`, but not `signing_only` and `verification_only`.. 11:48 < stevenroose> nvm, was somehow using version 0.11 and 0.6 togethre 11:58 < wumpus> heeh 12:11 < stevenroose> What's the easiest way to create a scriptSig with rust-bitcoin? I have the signature hash and the pubkey etc. Just manually? 12:13 < stevenroose> the sighash is just 1 byte appended to the signature right? 13:16 < Blackwolfsa> @BlueMatt I am opening new independent issues for the Bolt specs in issue #129. I have started with Bolt 9, but will move back to bolt 2 so we can ensure everything is tracked and we know when to check off a specific bolt on #129 13:19 < wumpus> stevenroose: "the sighash is just 1 byte appended to the signature right?" yes — no idea if rust-bitcoin has an official way of making them 13:33 < Blackwolfsa> @BlueMatt for 0.1 release do we worry about optional features? I am specifically looking at option_data_loss_protect on channel_reestablish messages 13:39 < stevenroose> wumpus: yeah somehow rust-bitcoin has sighashes as u32s, so I was a bit confused. But it just worked by doing things manually.. 13:49 < BlueMatt> wumpus: I presume you could get a rust compiler via the mrustc thing 13:49 < BlueMatt> though obviously that also depends on a c compiler with C++ 13:49 < BlueMatt> 14 13:52 < BlueMatt> Blackwolfsa: data loss (always) and upfront_shutdown (as an optional user-specified thing) would be nice, I think 13:52 < BlueMatt> I commented on your issue, though 13:52 < BlueMatt> Blackwolfsa: as for 0.1, its more of a milestone than release, really, 0.2 should be the first real "release" 13:52 < Blackwolfsa> cwl 13:52 < BlueMatt> I guess, technically, we dont *have* to do optional things for 0.1, but would be nice 13:53 < Blackwolfsa> I am going create issues for the missing "optional" stuff I find in the bolt spec, but I will mark for 0.2? 13:54 < Blackwolfsa> But thinking about it technically you can probably tick bolt9 on #129 as it doesnt have error conditions? All the error conditions are covered in their own bolts 13:56 < BlueMatt> yea, I guess bolt 9 is "implemented" in that at least we know what the flags mean in the LocalFlags object 13:56 < BlueMatt> will do 14:39 < BlueMatt> Blackwolfsa: we dont just want error conditions, we want spec compliance :p 14:40 < Blackwolfsa> true... 15:44 < andytoshi> stevenroose: re "creating scriptsigs", eventually the script_descriptor crate will do that 15:44 < andytoshi> but i need to clean that up, it has a bunch of weird algebra experiments in it right now because i was trying to prove various equiavelence properties of descriptors 16:09 < stevenroose> andytoshi: I'm trying to make a function that can extract an Address from a script. For all non-WitnessProgram variants of Address, that works perfect. But the WitnessProgram one is annoying me. Would the script descriptors stuff help with that too? 16:18 < andytoshi> depends what "annoying me" means :) 16:18 < andytoshi> probably yes 16:19 < andytoshi> well, it will enable workflows that are not "extract an address from a script" since that can't be unambiguously done 18:47 < esotericnonsense> meh 18:47 < esotericnonsense> today's project was to get my rust API backend working. 18:48 < esotericnonsense> so far I've spent about 5 hours trying to figure out how nginx does caching. now i've given up and i'm looking at other http caches like varnish. total time spent actually doing rust stuff: 30 mins. :p 18:48 < esotericnonsense> i regret not just NIH'ing it. almost 20:31 < esotericnonsense> well, it works now, just need to port over my weird custom calls which strip data from RPC's to make them more manageable on slow connections. 22:14 < stevenroose> Would there be interest in a method that can convert a `m/0'/0'/1` kinda string to a Vec? 22:18 < stevenroose> I was initially confused why there wasn't a DerivationPath type of some kind that just wraps a Vec. Any reason for that? I mean it's not strictly necessary.. I could even `impl FromStr for Vec` I guess 23:24 < sgeisler_> If you want to implement FromStr for it I think you have to wrap it into a newtype. Afaik you can only implement crate-local traits for all structs and all traits for crate-local structs, but not traits from other crates for structs from other crates because this would enable collisions between different implementations of the same trait for the same struct. 23:27 < sgeisler_> In rust-lightning-invoice I had to wrap every data structure I imported from other crates into it's own newtype to implement the serialization/deserialization trait from rust-bech32 for therm. 23:33 < stevenroose> sgeisler_: yeah noticed that. I really thought there was an exception for some core types like slices, options or vecs..