--- Day changed Wed Nov 07 2018
00:53 < dongcarl> andytoshi: got a few things later so I'm afk, had good discussions with sgeisler_ about the HMAC implementation, which would be simpler if we had associated constants......
00:53 < dongcarl> Oh well
02:09 < ariard> BlueMatt: hey #230 is ready for a new review pass
10:36 < BlueMatt> ariard: cool! will give it a look over the next few days, currently travelling
12:00 < andytoshi> BlueMatt: thanks for yelling at samson on twitter btw
13:45 < Blackwolfsa> @BlueMatt when you have time, please look at #244, I am not 100%  sure I understand the spec correctly.
13:45 < Blackwolfsa> The spec isnt clear enough for me on that
13:46 < Blackwolfsa> I also made a comment about the one field type that I think is incorrect. The spec mentions it as a number with size 33 bytes, we have it as a publickey
14:24 < ariard> Blackwolfsa: will review tonight it if you need it :)
15:46 < stevenroose> andytoshi: this is unfortunate: https://gist.github.com/stevenroose/8af1eb141c3f1f245aae1ce021a8308c
15:47 < stevenroose> Because Encodable is implemented for &[u8], these are two conflicting implementations, so I'll have to provide specific impls for the types that might want to be passed (for now just Transaction though)
15:57 < andytoshi> stevenroose: i think From is inappropriate anyway for something like this that's allocating a new vector
16:51 < andytoshi> BlueMatt: how do you feel about adding tim ruffing (real-or-random) as a maintainer of rust-secp? he's contributed to upstream libsecp (and is really good at noticing weird C shit) and has been working in rust for several years
16:51 < andytoshi> he also wrote the valueshuffle paper (coinjoin + CT) and has a phd in crypto
17:01 < stevenroose> andytoshi: yeah agreed. I removed it. Was experimenting.
17:14 < andytoshi> BTW i merged the 0.15 commit ad published rust-bitcoin 0.15
17:14 < andytoshi> my plan is for 0.16 to have no changes except to update to the new rust-secp; then 0.17 will do some more API breakage, add PSBT, etc
17:15 < andytoshi> and then maybe we need one more API break to deal with the network message modules, which are currently structured really shittily, but idk who's using them so i'm unsure how to fix them
17:15 < andytoshi> but then we'll pretty-much be at 1.0
17:16 < andytoshi> i'd like to have a 1.0 that works with rust 1.14, then 2.0 can move to a more modern rustc whenever that's feasible
17:35 < wraithm> Is there an implementation of a Ledger hardware wallet client in rust?
17:45 < andytoshi> wraithm: https://github.com/apoelstra/icebox .. but this is not the most usable thing in the world and I still haven't updated it to support the latest firmware (which did something breaking to the usb handshake)
17:45 < stevenroose> wraithm: I'm planning on working on one soon
17:45 < stevenroose> If you're planning the same, would like to cooperate!
17:45 < andytoshi> and it also doesn't yet support doing the verification check or encrypting communication, so you've gotta do that using the normal ledger tools
17:46 < stevenroose> wraithm: very recently put together a Trezor one: https://github.com/stevenroose/rust-trezor-api/ (not published yet because it depends on PSBT PR in rust-bitcoin)
17:52 < wraithm> Yes, I'm definitely down to cooperate. Maybe we could take andytoshi's implementation and split out the ledger part and start from there.
17:53 < andytoshi> it would be pretty cool if there were a lib that could handle both ledger and trezor
17:53 < wraithm> Yes, some sort of general hardware wallet interface would be great
18:52 < stevenroose> andytoshi: I think I disagree. From my early look at icboc's code and the Trezor lib, they are significantly different.  Both dependency wise and flow-wise.
18:53 < stevenroose> The Trezor flow is very confusing, tbh, and it really makes it impossible to just exchange messages deterministically. It can require some random user interaction stuff at any time and thus makes the interface a bit awkward. (Would love your feedback on the way I handled it, btw, was tricky, so I might have broken some good practice rules :D)
18:56 < andytoshi> ah ok
18:57 < andytoshi> heh, i know very little about the trezor actually (though i'm working on libsecp integration for it so maybe i'll have to learn ... but probably not, i can just hide out in the low-level crypto stuff :P)
18:57 < stevenroose> They could be like jointly maintained to get some unification of what kind of data structures they use etc, but I'd definitely keep them in separate crates.
18:57 < andytoshi> cool, good to know
18:57 < stevenroose> F.e. I built the Trezor sign-tx flow around PSBT, heavily using PSBT.
18:58 < stevenroose> Something similar could be done for Ledger I guess.
18:58 < andytoshi> yeah, though at this point it'd be a lot of translation work
18:58 < andytoshi> maybe a future firmware rev will directly support psbt
19:07 < wraithm> stevenroose: That's exactly what I'm looking for. Heavy PSBT Ledger workflow.
19:10 < stevenroose> andytoshi: Trezor also doesn't support PSBT
19:10 < stevenroose> But it has this flow where it asks random pieces of information from the tx and dependent txs etc and I made it so that you can extract all that info from a single PSBT.
19:11 < stevenroose> So you hand the lib a PSBT and it'll extract all the necessary pieces to hand them to the Trezor.
19:11 < stevenroose> (Probably untill the firmware and memory allows for just sending the entire PSBT :p)
19:13 < andytoshi> ah, i see. yeah, the ledger workflow could be made to work that way. ledger does this "pre-signed input" thing in non-segwit mode, and my current code stores those for a long time (it obtains them from the hw device when we first receive coins, instead of doing it when we spend them)
19:13 < andytoshi> oh, but i guess as long as the wallet software knows how to map outputs to those things, it can use psbt
19:25 < stevenroose> on another note, something that I do might be interested in creating a unified lib for is a "bitcoin explorers" thing. Like a generic interface that knows how to fulfill it with the different APIs.
19:27 < stevenroose> Since the APIs might not be the same, we might piggy-back the bitcoin core rpc (verbose mode) structs in the api.  Not sure that would work, but could be looked at.  Otherwise just custom structs that fit most explorers APIs.
20:19 < andytoshi> BlueMatt: super simple PR for rust-secp https://github.com/rust-bitcoin/rust-secp256k1/pull/80
22:29 < BlueMatt> andytoshi: lol, no problem (re: twitter)
22:29 < BlueMatt> andytoshi: re: tim: sure, also your project :p
22:30 < BlueMatt> andytoshi: is it really normal now to re-export all your deps?
22:30 < BlueMatt> that seems really....ugh
22:31 < andytoshi> BlueMatt: it's four characters :P
22:31 < BlueMatt> Blackwolfsa: will do, I'm pretty behind on stuff right now due to travel, though :(
22:31 < andytoshi> usually nobody even notices if you re-export your deps or not; they have to compile them regardless; but every so often there's a version mismatch and it's nice to be able to say "i want the rng from the rand crate that rust-secp is using, whatever that happens to be"
22:45 < BlueMatt> andytoshi: should we re-export them under something like rust-bitcoin::deps?
22:45 < BlueMatt> instead of at the root?
22:45 < andytoshi> sure, i'd be fine with that
22:45 < andytoshi> i guess you use `use bitcoin::*` and don't want weird crap coming in?
23:09 < stevenroose> dpc[m]: I'm trying to remove the macro from bitcoindrpc, I think I can make it quite ergonomic after all
23:23 < stevenroose> dpc[m]: anther corner case is methods that return an Optional value