--- Day changed Tue Oct 23 2018
05:03 < Blackwolfsa> Github-travis integrations seems to be not working. Travis reports builds as ok, but github reports them as pending travis build...
11:08 < stevenroose> Blackwolfsa: that happens quite often actually. But esp yesterday with all GitHub being quirky, yeah that's probably normal.  Repush to trigger new builds could solve that if you're not allowed to just merge with "pending" tests..
11:19 < stevenroose> damn, spent half an hour going through why I got a reversed hash in my logs (after trezor roundtrip), was thinking of wrong serialization etc
11:19 < stevenroose> untill I read this: /// Output the raw sha256d hash, not reversing it (unlike Display and what Core does for user display)
11:20 < stevenroose> Debug for Sha256dHash impl.. any reason why that is the case and it's not just the same as Display? It's quite confusing tbh :D
15:02 < andytoshi> stevenroose: because the debug output reflects the actual hash that you'd get out of `sha256sum` or that you'll see in serialization of any network message
15:03 < andytoshi> we can change it, i actually forgot that `Debug` did that, i've been manually reversing my hashes from rust-bitcoin for years
15:03 < andytoshi> i agree it's confusing
15:04 < andytoshi> but the reasoning was to match sha256sum
15:10 < stevenroose> Personally I would have Debug just mirror Display and if someone wants to hex the actual data, use the to_bytes or as_bytes and use `{:x}` or so..
15:11 < andytoshi> yeah, if only :x was implemented for &[u8]..
15:11 < stevenroose> Not sure if it would break things for people relying on that
15:11 < stevenroose> It is not?? :'D
15:11 < andytoshi> IMO changing `Debug` output is never a breaking change
15:11 < andytoshi> but also, we've made a bunch of breaking changes since 0.14 already
15:11 < stevenroose> True. Shouldn't be for sure.
15:11 < stevenroose> I can quickly PR it if you're fine with that?
15:11 < andytoshi> sure
15:12 < stevenroose> Had another question: not sure if you're familiar with PSBT, (cc dongcarl) does PSBT have an explicit indicator for change outputs?
15:12 < stevenroose> You'd probably see that an output is change if the hd_keypaths are specified. But thats kinda implicit.
15:13 < stevenroose> F.e. that would make it impossible to do change without BIP32 wallets
15:14 < stevenroose> (Asking because Trezor expects different metadata for change vs non-change outputs otherwise it will think the total value you're spending is both change + non-change. And I'm kinda trying to have the whole Trezor lib use PSBT instead of some explicit stuff. (Not sure if that's smart, though.)
15:15 < andytoshi> no, psbt assumes that your wallet can recognize its own change
15:15 < andytoshi> so if your wallet is trying to translate PSBT to trezor-ese, you've gotta know what bip32 paths the trezor knows the keys to
15:17 < stevenroose> It's more that a wallet will be "constructing trezor-ese PSBTs".
15:18 < stevenroose> I guess (read: hope) that if it provides paths that the Trezor doesn't know, the trezor will just ignore them and consider it non-change. Graceful fallback, right?
15:28 < andytoshi> i would assume so
15:29 < andytoshi> if it chokes on them that's antithetical to the point of psbt, and means that trezors can't do coinjoins (but this wouldn't surprise me..)
15:29 < andytoshi> and if it reads them as change then you should responsibly disclose that :)
17:12 < stevenroose> I saw statements in the code like // for coinjoin :D So they thought/think about it, not sure it works :D
17:12 < stevenroose> / reserved for external inputs (coinjoin)
17:12 < stevenroose> That could be useful to play with for the challenge input for the proof-of-reserves :D
17:13 < stevenroose> But that would break the idea that the lib only relies on PSBT info :( Well, i'll see. For now I want to get normal txs working.
18:13 < stevenroose> So Trezor, instead of asking serialized dependent txs (probably size issue), it asks for all inputs and ouputs separately (in the form of metadata objects, so it rebuilds the txs on the fly) and then fails with "invalid prevhash", suggesting I'm probably not providing some info for which it's assuming default info so that the hash isn't the same..
18:13 < stevenroose> What's work with a device that has a MB in RAM? :D
18:59 < andytoshi> the segwit sighash scheme roughly matches that model
19:24 < BlueMatt> Blackwolfsa: hey sorry I didnt get things finished yesterday
19:24 < BlueMatt> did my comment answer your question?
20:22 < stevenroose> Any thought on logging in Rust? I saw the log lib that is supposed to provide an interface for consumers to use later. Does it make sense for a lib to utilize the log interface? It could give some overhead if the user of the lib doesn't want logging, I guess.
20:22 < BlueMatt> stevenroose: the rust-lightning logger has a similar interface but also logs via macros that you can disable at compile-time
20:22 < BlueMatt> https://docs.rs/lightning/0.0.5/lightning/util/logger/index.html
20:23 < stevenroose> BlueMatt: what was the rationale for having your own logger as opposed to a standardized one?
20:23 < BlueMatt> not taking a needless dependency?
20:23 < stevenroose> Just curious. Thing is as a lib dev, you try to make as few decisions as possible for your users :p
20:24 < BlueMatt> I mean adding a logger is really not much code
20:24 < BlueMatt> and a user writing a wrapper that takes ours and shoves it into the log crate would be super trivial
20:24 < BlueMatt> but its still an interface you have to provide, like everything in rust-lightning
20:24 < BlueMatt> the log stuff in rust-lightning has no concept for writing to stdout or a file or anything
20:24 < BlueMatt> it just calls your code and tells you about lines you may want to log
20:25 < stevenroose> K. log seems to have just two trivial dependencies, so I don't think it's that heavy. But I don't know what components in rust-lightning would be suitable for independent reuse either of course.
20:25 < stevenroose> Yeah that's exactly what the log crate is doing as well.
20:26 < BlueMatt> the question isnt whether there are transitive deps that log adds, but log itself is a dep
20:26 < stevenroose> But do you think it makes sense for, say, a Trezor or bitcoind-rpc lib to utilize this crate? or just do no logging at all?
20:26 < BlueMatt> like, lets not turn rust into javascript where people depend on a library for something they can write themselves in 20 lines of code
20:26 < BlueMatt> no fucking rust-leftpad, please
20:27 < BlueMatt> problem with things like rust-lightning is all your deps are also security weaknesses
20:27 < BlueMatt> cause if that dep gets updated then your users are now calling new code from some random third-party
20:28 < andytoshi> BlueMatt: in fairness, logging to anything but stdout/stderr requires a global log mutex which can't really be written in safe code (well, it requires static_mutex). so log backends are nontrivial. and `log` crate provides standard types for connecting to various backends
20:28 < BlueMatt> so my strong, strong preference is to add libraries where reimplementing it is nontrivial
20:28 < BlueMatt> I mean technically, but practically not at all
20:28 < andytoshi> we don't use `log` in Liquid either, for the reasons you're listing, but that's the reason for it to exist
20:28 < BlueMatt> calling fprintf() works sans-lock 99.9% of the time
20:28 < BlueMatt> well, 99.99%
20:29 < andytoshi> not if you call it twice in a row as part of printing the same line
20:29 < BlueMatt> sure, so dont do that :p
20:29 < BlueMatt> but taking rust-lightning's log calls and printing them is a one-liner: https://github.com/rust-bitcoin/rust-lightning/blob/master/src/util/test_utils.rs#L189
20:29 < stevenroose> log has 1 dep (cfg-if) which has itself no deps
20:29 < BlueMatt> log itself is a dep :p
20:30 < BlueMatt> its fancier than things like rust-lightning need, too
20:30 < andytoshi> well, what if you wanted to log to a syslog socket for example
20:30 < BlueMatt> indeed, and for rust-lightning if you want to do that the user can trivially do so
20:30 < BlueMatt> ie if they want something fancy that log provides, they can depend on log and then pass the log entires from rust-lightning into log
20:30 < BlueMatt> would be a 10-LoC wrapper to do so, I presume
20:31 < andytoshi> you can't really wrap a direct call to println
20:31 < andytoshi> and if someone wanted to log in rfc5424-compliant format, and someone else wanted json, or something like that, things would get even hairier
20:31 < BlueMatt> hmm?
20:32 < stevenroose> yeah, that's why log doesn't do any of that, it just provides macros to produce a stream of messages that can be consumed by anyone that's interested in them
20:32 < andytoshi> oh, wait, i see
20:32 < BlueMatt> rust-lightning makes its users provide an interface which simply takes a log entry: https://docs.rs/lightning/0.0.5/lightning/util/logger/struct.Record.html
20:32 < andytoshi> i misread your code BlueMatt, it's more generic than i thought
20:32 < BlueMatt> the user is then free to do anything they want with it
20:32 < andytoshi> yep i see now
20:32 < BlueMatt> including call log, or printf, or whatever
20:32 < BlueMatt> the above link is just a simple client used in #[cfg(test)] to log things
20:34 < stevenroose> ok, so back to my question :D let me rephrase: should a general-purpose lib do logging at all? regardless of custom/standard interface.. :)
20:35 < stevenroose> I'm on the edge of just doing some printlns where I'm debugging, but if it makes sense, could just as well add logs everywhere for them to stay
20:35 < BlueMatt> depends on the lib? Something like rust-lightning that has a ton of protocol-state-machinery inside that it does't really expose via any interfaces probably needs to for debugging purposes
20:35 < BlueMatt> for something like libsecp or rust-bitcoin, well, there's not much more that the lib does that it doesn't tell you about
20:36 < BlueMatt> yay non-answer :P
20:37 < stevenroose> Yeah thinking trezor-api or bitcoindrpc
20:37 < stevenroose> For debugging it totally makes sense to see round tripped messages etc
20:37 < stevenroose> (for trezor, i.e.)
20:38 < stevenroose> But it's not like it's a moving system like lightning stuff. In the sense that once it works, it should just work  and no one should really care about what it's doing
20:58 < andytoshi> it's helpful for libraries to log, yes. see for example what hyper does
21:24 < andytoshi> lol, somebody posted an insane way to emulate higher-kinded-types in rust, and petertodd replied with "cool, i do that too!" https://www.reddit.com/r/rust/comments/9qihgo/rust_has_higher_kinded_types_already_sort_of/