--- Log opened Wed Dec 19 00:00:56 2018
00:28 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #rust-bitcoin
01:29 < wumpus> sgeisler: the connection overhead itself is neglible; however, opening a new connection for every command can exhaust ephermal ports with high-frequency calls
01:29 < wumpus> sgeisler: this is why the python rpc reuses the same connection if possible
01:30 < wumpus> agree taht a connection pool is overkill
07:59 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #rust-bitcoin
08:39 < BlueMatt> andytoshi: wellll, thats on my rather fast x86 laptop, I am worried about that on any kind of embedded device or anything
08:41 < BlueMatt> andytoshi: before you make it default I'd like to see it run on arm
08:41 < BlueMatt> at least
08:50 < andytoshi> ok, sure, good point
10:34 < BlueMatt> lol, welp, went to install rustup to try to run bench on my workstation and all the rustup builds of cargo are corrupt
10:34 < BlueMatt> even stable
10:34 < BlueMatt> immediate Illegal Instruction
10:35 < BlueMatt> andytoshi: anyway, so my preference would be to merge 18/19 as-is and we can revisit using it as a default later
10:35 < BlueMatt> we could also depend on subtle
10:36 < BlueMatt> but I'm kinda meh on the idea of anything that takes the "outsmart the compiler" approach
10:36 < BlueMatt> cause you never know what may happen on strage architectures/someone using a different llvm version/different compilation flags/lto+calling-it-a-different-way/etc/etc
10:37 < andytoshi> yeah
10:37 < andytoshi> especially because rust gives llvm soo much information
10:41 < BlueMatt> lol "official cargo binaries dont work at all" filed aug 2, 2017 https://github.com/rust-lang/rust/issues/43610
11:31 < stevenroose> Is it normal for an input witness to start with an empty element?
11:32 < andytoshi> if it's a multisig yes
11:32 < andytoshi> well, "start with" meaning the last element
11:32 < andytoshi> s/last/bottommost/
11:59 < BlueMatt> ffs the cc crate doesnt currently compile
11:59 < BlueMatt> even on rustc 1.29
11:59 < BlueMatt> this is absurd
12:00 < BlueMatt> are you fucking serious? https://github.com/alexcrichton/cc-rs/commit/228513449f3e2674cdce0f53206c9449af9d3778
12:00 < BlueMatt> why is this ok?
12:00 < BlueMatt> you're fucking kidding me, right?
12:02 < BlueMatt> ffs https://github.com/alexcrichton/cc-rs/issues/364
12:03 < stevenroose> andytoshi: I took a tx from the blockchain and decoded it with rust-bitcoin. The empty element is the first on in the vec. Is the vec "to be pushed on the stack" so that it's reversed?
12:03 < stevenroose> Do you think it makes more sense to display that vector in reverse?
12:03 < gwillen> BlueMatt: from context of the cargo bug it kind of looks like it's trying to call RDRAND
12:03 < BlueMatt> andytoshi: I guess we have to peg everything to an old cc
12:03 < BlueMatt> gwillen: yea, looks like a dependency of a dependency, too (git calling openssl)
12:04 < BlueMatt> gwillen: hence why the debian-provided one works fine, cause it probably dynamic links libssl which doesn't build backdoored garbage
12:19 < andytoshi> BlueMatt: <.< kk
12:29 < real_or_random> BlueMatt: what's the purpose of pinning the version? to avoid using the current version which does not compile?
12:29 < BlueMatt> andytoshi: Maybe we need to start maintaining a fork of cc called cc-not-stupid?
12:29 < BlueMatt> real_or_random: yes
12:29 < BlueMatt> real_or_random: upstream is broken, gotta use a not-broken upstream
12:30 < real_or_random> :/
12:30 < BlueMatt> see https://github.com/alexcrichton/cc-rs/pull/365
12:31 < BlueMatt> I really hate the rust ecosystem
12:31 < andytoshi> BlueMatt: eh, we'll just pin to an old version
12:32 < andytoshi> this crate has no reason to change really
12:32 < andytoshi> ever
12:32 < andytoshi> real_or_random: this is the second time this has happened with this crate
12:33 < BlueMatt> lol I love that alex has a binned response for "fuck you, I dont care about rustcs except bleeding edge, sorry rust ecosystem"
12:35 < andytoshi> lol. yeah.
12:38 < BlueMatt> dude. seriously. fuck the rust ecosystem
12:39 < andytoshi> it's pretty disappointing that alex is behaving like this. he is a compiler dev :/
12:40 < andytoshi> when the ruby-on-rails or javascript parts of the rust community do it, it doesn't really faze me :P
12:40 < BlueMatt> rust has imported so much of javascript's stupid
12:40 < andytoshi> yeah
12:40 < BlueMatt> indeed
12:40 < BlueMatt> actually, wait, javascript is so much better than this lol
12:40 < BlueMatt> cause people have to care about old versions
12:41 < andytoshi> old browser versions, yes, if you're writing client-side website code
12:41 < andytoshi> but javascript is everywhere now :P
12:41 < BlueMatt> ok, fair
12:41 < BlueMatt> anyway, i love how the whole rust community just assumes that if you dont use rustup + latest stable everything is your fault
12:41 < BlueMatt> its....downright absurd
12:42 < BlueMatt> andytoshi: you wanna spin a secp release?
12:47 < BlueMatt> andytoshi: should i just merge the secp cc dep change or do we want to wait for alex to spin a release and screw us again
12:55 < andytoshi> BlueMatt: just merge it on our end
12:55 < andytoshi> then sure i'll do a new release
12:57 < BlueMatt> andytoshi: k, done :(
12:58 < BlueMatt> then we'll have to update rust-bitcoin........
12:58 < BlueMatt> which is nontrivial :(
12:58 < andytoshi> ah, shit, hmm
12:59 < BlueMatt> then I'll just swap rust-lightning to git versions of rust-bitcoin and rust-secp
12:59 < BlueMatt> yea, this is fucking absurd
12:59 < andytoshi> let's backport the fix to rust-secp 0.11
12:59 < BlueMatt> hmm, ok
12:59 < andytoshi> there's no branch but there is a tag that i can push to
12:59 < BlueMatt> well you can make a branch?
12:59 < andytoshi> sure
12:59 < BlueMatt> just make a branch from the 0.11 tag?
13:00 < andytoshi> branch pushed. called 0.11
13:00 < BlueMatt> thanks
13:00 < andytoshi> should match published 0.11.5
13:00 < BlueMatt> k, sec I'll pr against it
13:00 < andytoshi> thanks
13:03 < BlueMatt> ok, then I'm gonna swap rust-lightning to git version of bitcoin_hashes cause we have our own cc dep (for kinda awkward reasons)
13:03 < BlueMatt> oh, fuck, i guess we need rust-bitcoinconsensus too?
13:03 < andytoshi> :/ yep
13:04 < BlueMatt> well it needs bumped to latest bitcoin core anyway
13:19 < stevenroose> BlueMatt: was your comment before related to this build not working: https://travis-ci.org/rust-bitcoin/rust-bitcoin/jobs/470196923
13:19 < stevenroose> it says "could not compile 'cc'"
13:19 < BlueMatt> stevenroose: yes
13:20 < BlueMatt> upstream cc broke cause the rust ecosystem is immature af
13:20 < BlueMatt> stevenroose: we're working on it, but gotta go pin the dep on a bunch of crates
13:20 < BlueMatt> andytoshi: can you ack https://github.com/rust-bitcoin/rust-bitcoinconsensus/pull/7 and then I'll email tamas to do a release
13:20 < stevenroose> sure just to know I don't need to go dive into why my PR fails
13:20 < stevenroose> thanks, btw!
13:22 < andytoshi> BlueMatt: done .. i couldn't find the review button so i just said ACK.
13:22 < andytoshi> btw i asked on https://github.com/rust-bitcoin/rust-secp256k1/pull/86 if you can bump the version as well
13:22 < BlueMatt> ok, I'll email him
13:22 < andytoshi> to save a step
13:22 < BlueMatt> will do
13:23 < BlueMatt> andytoshi: done
13:23 < BlueMatt> well, in a second commit
13:23 < andytoshi> awesome thx
13:33 < andytoshi> published rust-secp 0.11.6. rust-bitcoin should work now
13:35 < BlueMatt> doesnt it still need consensus for travis?
13:35 < andytoshi> oh, right, yeah
13:35 < BlueMatt> ah, looks like tamas just merged it
13:36 < BlueMatt> so I guess we'll get a bump soon
13:47 < BlueMatt> ok, tamas is done
13:47 < BlueMatt> everything should be good now if we re-run travis
14:05 -!- bungled [~bungle@pool-96-230-222-55.bstnma.fios.verizon.net] has joined #rust-bitcoin
14:46 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
15:01 -!- bungled is now known as thismyspout
15:22 -!- thismyspout [~bungle@pool-96-230-222-55.bstnma.fios.verizon.net] has quit [Quit: Leaving]
15:26 < dongcarl> BlueMatt: Do you think we need testing for the fuzzing stubs?
15:34 < BlueMatt> dongcarl: meh? I mean I guess it would be nice to know they dont crash, but even if they do they'll just break downstream mostly-local-only-testing
15:35 < BlueMatt> but, i guess they'd break rust-bitcoin travis, sooooo
15:39 < BlueMatt> andytoshi: I dunno if you have anything to add to https://github.com/alexcrichton/cc-rs/issues/364
15:39 < BlueMatt> I didnt want to go down the full route of "sorry, rust just needs to fucking grow up" right away, but you're welcome to dump that there if you want
15:43 < dongcarl> BlueMatt: what is cc-rs used for?
15:44 < BlueMatt> dongcarl: build-dependency to call your local C compiler to compile anything C/C++
15:44 < BlueMatt> eg we use it to build libsecp and libbitcoinconsensus in the respective crates
17:13 < BlueMatt> ariard: were you suggesting something like ln::full_tests::{monitor,general,etc}?
17:18 < ariard> BlueMatt: hmm well at least yes, was looking on bitcoin core and others ln implementations, having a clear seperation between unit tests and more functionnal/integration ones?
17:18 < ariard> and also quoting directly in tests bolt specs to ease review of what it's implemented/tested
17:18 < BlueMatt> well those tests kinda *are* the functional tests....
17:19 < BlueMatt> its harder to quote bolts for functional tests cause they cover so many bits
17:19 < ariard> yes that my point, and so it's hard to track what it's implemented and not
17:19 < BlueMatt> hmm?
17:21 < ariard> what do you think of neonknight PR, where he quotes directly bolts in lines test?
17:23 < BlueMatt> oh i love that, but thats kinda orthogonal to moving them somewhere else?
17:23 < BlueMatt> and a lot of work to re-add them
17:23 < BlueMatt> we do generally probably need more comments in our tests, not that thats not mostly my fault
17:23 < ariard> yes I know that's a lot of work, but that would maybe spare them bad surprises latter
17:24 < ariard> we'll add more bolt comments in my already written tests
17:24 < ariard> agree it's kinda orthogonal to moving them but well was timely to introduce also this point
17:25 < ariard> just to ease writing/review and don't rewrite again same tests
17:26 < BlueMatt> I mean BOLT comments are definitely nice, but I'm more interested in high level comments of the form like here: https://github.com/rust-bitcoin/rust-lightning/blob/master/src/ln/channelmanager.rs#L9148
17:26 < BlueMatt> and then comments through the test that explain which step you're on
17:26 < BlueMatt> so that you can easily look at a test and figure out what its trying to do, in what steps
17:27 < BlueMatt> ariard: btw I'm gonna take the bitcoin_hashes pr, just because it will clear out our cc dependency
17:28 < ariard> ok fine, for comments will stuck on that
17:38 < BlueMatt> dongcarl: whats left to land bitcoin_hashes for rust-bitcoin? Do we just need #15?
17:39 < dongcarl> Yup, I’ll push up my local branch for the integration tnt
17:40 < BlueMatt> kool
17:40 < BlueMatt> wasm here we come
17:41 < dongcarl> Woop woop!
18:05 < dongcarl> BlueMatt: mmmm seems like we need a `from_inner` as well
18:08 < ariard> writing tests, tx version is both enforced at policy level and consensus level right ?
18:14 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 268 seconds]
18:18 < BlueMatt> dongcarl: for where?
18:20 < dongcarl> Mostly for `impl<D: Decoder> Decodable<D> for sha256d::Hash`, where there's no need for the slice length checking nonsence
18:20 < dongcarl> nonsense*
18:24 < dongcarl> BlueMatt: ping
18:25 < BlueMatt> ah, right, yes, we have to implement decoders cause they're used in inputs
18:25 < BlueMatt> hmmmmmm
18:26 < BlueMatt> may want to get with andytoshi and think about this one, cause he was thinking about using them in secp to avoid unwrap()s/Err return types
18:26 < BlueMatt> i mean i guess since we have from_slice thats not really problematic
18:26 < BlueMatt> more a question of if we want to go down that route further
18:28 < dongcarl> BlueMatt: Not sure I'm fully understanding... Use `*_inner` in secp?
18:33 < BlueMatt> dongcarl: no, more like keep the rust-bitcoin Sha256dHash type as a distinct type (that can be converted from the bitcoin_hashes sha256d Hash type)
18:33 < BlueMatt> dongcarl: and then remove the from_slice
18:33 < BlueMatt> so that the bitcoin_hash Hash types are "type-safe"
18:33 < BlueMatt> in that they can only be generated by hashing something
18:34 < BlueMatt> then rust-secp can assume that such types are, indeed, random bytes and "guaranteed" to not be invalid private keys
18:34 < BlueMatt> ie they cant end up all-0s in a type-safe way
18:34 < dongcarl> Ah! That's cool
18:34 < dongcarl> BlueMatt: Okay well I guess we'll need to wait for that
18:51 < andytoshi> dongcarl: still haven't nailed down the design
18:52 < andytoshi> rust-secp has a ThirtyTwoByteHash trait now that can be used to convert into messagehashes etc without errors
18:52 < andytoshi> and i have an idea to implement that trait for the bitcoin_hashes hashes....but then either bitcoin-hashes or rust-secp has to depend on the other
18:52 < andytoshi> and i don't like that, and i can't decide which direction is less bad
18:52 < dongcarl> :-/
18:52 < andytoshi> alternately, as matt says, i could newtype the hash in rust-bitcoin, which already depends on both crates
18:53 < andytoshi> then implement the trait on the newtype ... but then, i've got a lot of types flying around
18:53 < andytoshi> which also isn't great
18:53 < andytoshi> I think I'm going to make rust-secp depend on bitcoin_hashes (but behind a feature-gate) and do it that way
18:53 < andytoshi> so rust-secp 0.13 will have that
18:54 < dongcarl> This might be naive, but to me it seems like there just needs to be 2 types. One that is only generated by hashing something and one that doesn't need to be. And the first one can be converted into the second one, but not the other way around?
18:54 < andytoshi> i'll try to get this implemented and PR'd before christmas ... but i have like 1000 little things like this to do and it makes it hard to focus enough to do any of them :)
18:55 < andytoshi> dongcarl: that's roughly correct
18:55 < andytoshi> so the rust-secp Message type is the "can only be generated by hashing something" thing
18:55 < dongcarl> Right
18:55 < andytoshi> and [u8; 32] is the other one :P
18:56 < andytoshi> but then there are also types for each of the different hashes
18:56 < dongcarl> Right, yeah I think since rust-secp has a concept of what a Hash is and bitcoin_hashes doesn't have a clue what keys are, the current plan works
18:56 < andytoshi> and there's also a SecretKey type which i'm uncertain how it fits into this
18:57 < dongcarl> :-/
18:57 < dongcarl> Oh well, if you have more ideas, we can talk on the issue
18:57 < andytoshi> i think i'm just gonna leave SecretKey alone, it's a dangerous type anyway, i don't care too much if it's unergonomic to use
18:57 < andytoshi> i think i've got a plan in mind. i've just gotta follow through
18:57 < dongcarl> Sounds good. Lmk!
18:57 < andytoshi> will do
23:22 -!- grubles [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection]
--- Log closed Thu Dec 20 00:00:56 2018