--- Log opened Sun Aug 04 00:00:30 2019
01:22 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:2c32:3a0a:eb60:c84f] has joined #rust-bitcoin
03:19 < belcher> elichai2 i dont know much details about bulletproofs but the best option in your situation is always "give it a go / try it and see"
04:07 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:2c32:3a0a:eb60:c84f] has quit [Read error: Connection reset by peer]
04:08 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:2c32:3a0a:eb60:c84f] has joined #rust-bitcoin
04:09 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:2c32:3a0a:eb60:c84f] has quit [Read error: Connection reset by peer]
04:09 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:2c32:3a0a:eb60:c84f] has joined #rust-bitcoin
06:26 -!- aleru [496680ee@gateway/web/cgi-irc/kiwiirc.com/ip.73.102.128.238] has joined #rust-bitcoin
06:54 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:2c32:3a0a:eb60:c84f] has quit [Ping timeout: 252 seconds]
07:03 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has joined #rust-bitcoin
07:09 -!- aleru [496680ee@gateway/web/cgi-irc/kiwiirc.com/ip.73.102.128.238] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
07:16 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has quit [Remote host closed the connection]
07:17 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has joined #rust-bitcoin
07:20 -!- aleru [496680ee@gateway/web/cgi-irc/kiwiirc.com/ip.73.102.128.238] has joined #rust-bitcoin
07:21 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has quit [Ping timeout: 250 seconds]
07:48 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has joined #rust-bitcoin
07:52 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has quit [Ping timeout: 252 seconds]
08:31 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has joined #rust-bitcoin
08:41 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has quit [Remote host closed the connection]
08:41 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has joined #rust-bitcoin
08:47 -!- titanbiscuit [~tbisk@91.203.70.189] has joined #rust-bitcoin
09:21 < andytoshi> elichai2: in what language?
09:22 < andytoshi> the short answer is that it's "not hard" to get something that works
09:23 < andytoshi> but to get reasonable performance you need a multiexponentiation algorithm
09:23 < andytoshi> and to support both rangeproofs and circuits you want to abstract out the inner product argument
09:23 < elichai2> I want to do it in Rust, though for now I'm reading a book instead, might give it a shoot next weekend lol
09:23 < elichai2> I meant rangeproofs only, something more general requires way more work of course
09:23 < andytoshi> and if you want to support batch verification, and batching circuits with rangeproofs, you'll find that it's hard to connect everything together
09:24 < andytoshi> although if you look at what the dalek people did, you'll see they had a waaaay easier time of this than I did, because rust has closures and iterators
09:24 < andytoshi> and with C you have to manually build everything out of function pointers and feed them across several layers of abstraction
09:24 < elichai2> And how much is reasonable?
09:24 < elichai2> If it's less than 5 seconds I consider it enough as a PoC (not aiming to do anything production quality)
09:25 < elichai2> Ow function pointers  :/
09:26 < elichai2> But I'll look at daleks implementation (though I really like implementing stuff from the papers only, without looking at other implementations)
09:36 < andytoshi> well, with my implementation on my laptop i can make a 64-bit rangeproof in 21ms and verify in 2.5ms, without using the endomorphism optimization. i can batch verify in about 250µs
09:38 < elichai2> Btw why is your implementation just in the grin fork and not in secp256k1-zkp?
09:38 < elichai2> And that's great performance
09:50 < andytoshi> well dalek is 25% faster because they have better algebra and almost 3x faster using hw accelleration
09:50 < andytoshi> and because the grin people merged my code and deployed a blockchain with it even though it hadn't been finalized (and i think i did hardfork them a couple times)
09:51 < andytoshi> i want to change my implementation to use merlin for all of its hashes
09:51 < andytoshi> so i'm putting off merging it until i get around to it, or until blockstream wants bulletproofs in liquid
09:52 < elichai2> Why merlin specifically? (I've seen that dalek use it too) is it faster than blake2?
09:52 < andytoshi> it standardizes a lot of things related to random oracle challenges in a safe way
09:53 < andytoshi> the speed is basically irrelevant
11:17 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
11:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
13:54 < aleru> Hi! I am a relative novice so apologies in advance if these questions seem silly. I have a few prospective test functions that could be added into rust-bitcoin, I realized earlier that none of the test functions in the library will compile. I am wondering if this is to be expected? or perhaps i am missing something
14:00 < aleru> to clarify the change  is just resolving two of the TODO's of a test function so it is not a big deal, but more than anything I am curious what I am doing wrong (running "cargo test"  leads to rust throwing errors and aborting)
14:43 -!- reallll [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
15:16 -!- titanbiscuit [~tbisk@91.203.70.189] has quit [Ping timeout: 248 seconds]
15:16 < elichai2> aleru: can you post the exact errors/code?
15:22 -!- titanbiscuit [~tbisk@91.203.70.189] has joined #rust-bitcoin
16:20 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has quit []
17:35 < aleru> Okay, here it is:
17:37 < aleru> $ cargo test
17:38 < aleru> error[E0658]: imports can only refer to extern crate names passed with '--extern' on a stable channel,,,
17:39 < aleru> error[E0658]: 'Self' struct constructors are unstable (see issue #51994)
17:41 < aleru> there are three of the first error message and four of the second. **I am running my altered version of rust-bitcoin but the same errors show up on the master when i try to run cargo test
17:49 < gwillen> aleru: what rust/cargo versions? (cargo --version, rustup show)
17:49 < gwillen> (I don't have great insight here but I strongly suspect it will be related, so I'll save you some time for when someone more clueful gets here :-) )
17:50 < gwillen> (the readme says it should build with a huge range of versions but I'm suspicious about how reliable that promise is, for versions the devs themselves aren't using)
17:51 < aleru> Cargo 1.31.0 (339d9f9c8 2018-11-16)
17:52 < aleru> rustc 1.31.1 (b6c32da9b 2018-12-18)
17:56 < gwillen> coincidentally(?) that's the same version I have, and indeed, I get similar errors (only for 'cargo test' not 'cargo build', so I guess it's only the tests that have the issue?)
17:57 < gwillen> ahhhhh, all the errors are in building the 'getrandom' crate
17:58 < gwillen> I don't recall how crates are supposed to express their dependencies on rust versions but it seems like that crate (which is third party) has not done so properly or something
17:58 < gwillen> I've seen this kind of issue before when dependencies get updated, they aren't always good about it, a newer or older version of getrandom may be the fix (or a newer compiler might be an adequate workaround, not sure)
18:04 < aleru> sounds good gwillen, part of the reason I wanted to figure this out is because i wanted to make sure the minor additions (testing negative numbers  in consensus/encode.rs) work  correctly
18:04 < gwillen> *nods*
18:05 < gwillen> if I understood a little more about rust dependency management I could be more help -- it's curious that getrandom only gets pulled in when testing but I can't see why, it's probably related to the 'rand' feature flag in secp256k1 but I don't know how to turn that flag off or whether you could
18:07 < gwillen> I'm going to try just building with rustc 1.36.0 and see if it goes away, I suspect it might
18:07 < gwillen> which is not _great_ but could at least get you going
18:12 < gwillen> aleru: yeah, it works with the latest rustc I get from 'rustup update' which is rustc 1.36.0 (a53f9df32 2019-07-03)
18:12 < gwillen> so I would suggest using that just to get going -- at some point hopefully someone will take a look at the dependency issue and either fix or document it
18:15 -!- TamasBlummer1 [~Thunderbi@p200300DD671264051DCE7C9489E69676.dip0.t-ipconnect.de] has joined #rust-bitcoin
18:17 -!- TamasBlummer [~Thunderbi@p200300DD67126456F597D2DE45B4E866.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
18:17 -!- TamasBlummer1 is now known as TamasBlummer
18:17 < aleru> Awesome! the tests passed, thanks for the help :)
18:18 < gwillen> no problem!
18:19 < aleru> by the way I am wondering about the general culture of open source, is it normally okay to submit a PR even if I dont really know for sure if it is something that should be merged? Or should i be waiting until i have near certainty.
18:25 < gwillen> it depends on a couple things
18:26 < gwillen> the biggest one is how much work the PR is
18:26 < gwillen> if it's easy it's usually fine to just do it and submit it
18:26 < gwillen> if it's a lot of work, or especially if the design of it might be something that could change a lot or people might have strong opinions about, you can waste a lot of work if you do it without talking to someone first
18:27 < gwillen> if it's filling in a TODO that's already there in the code, and there's really one obvious way to do it, you are probably pretty safe
18:27 < gwillen> but especially your first time contributing to a project be aware that there might be things you don't know, and you might end up having to redo it, so don't do it if you'd be upset to have to redo it
18:28 < gwillen> (also there's some aspect of the culture of the project, I wouldn't worry about it in this case but some people are just dicks and will be mad you didn't check with them first)
18:29 < gwillen> if there's an IRC channel, I will often go on IRC and describe what I'm going to do, and get one of the maintainers (who you can find by checking github commit history for people who do a lot of commits) to say that sounds ok
18:29 < gwillen> and then namedrop them in the pull request :-)
18:30 < gwillen> (i.e. "I chatted with so-and-so on such-and-such channel on $date, and they said this approach sounded reasonable to try")
18:31 < aleru> Okay :) thanks for the tips
18:38 < gwillen> np!
18:50 < elichai2> aleru: sorry, missed it without the tag, but I see people already helped you
18:51 < gwillen> elichai2: it seems like it's still the case that 'cargo test' fails due to dependency issues on rustc 1.31.1
18:52 < gwillen> upgrading the compiler is a good workaround, but the readme does claim old versions should work
18:54 < elichai2> Hmm I think we test with latest and with 1.22 but I'll install 1.31 and give it a try (we're talking about rust-bitcoin, right?)
18:57 < gwillen> yeah
18:57 < gwillen> the problem is the dependency 'getrandom' which does not seem to build under 1.31.1 at its latest version
18:58 < gwillen> which is only pulled in during test for some reason I don't quite understand; it's an indirect dependency of secp256k1, probably related to the 'rand' feature I expect?
18:58 < elichai2> Interesting. I see those errors, ill try narrowing them down
18:59 < gwillen> the 'rand' crate advertises that it works with both std and no_std, and I wonder if it is doing shenanigans related to that -- otherwise I'm surprised to see importing std giving an error
19:01 < elichai2> so it looks like getrandom published a new version that breaks backwards compatibility
19:01 < gwillen> that makes sense -- the Struct error looks like they are just using a new feature
19:02 < elichai2> https://github.com/rust-random/getrandom/compare/v0.1.6...master
19:02 < elichai2> 1.22 obviously also fails
19:03 < elichai2> so we should either add `getrandom="=0.1.6"` in the dev-dependencies, or try to convince upstream
19:09 < elichai2> will see what they say https://github.com/rust-random/getrandom/issues/75
19:20 < elichai2> The Errors just disappeared. WHAT
19:20 < elichai2> gwillen: aleru: any of  you still here?
19:25 < gwillen> uhhhh lol what
19:25 < gwillen> I'm still here
19:26 < gwillen> are you running 'cargo test' not just 'cargo build'?
19:28 < elichai2> gwillen: yes. can you try renaming Cargo.lock and deleting `./target/` and running again? (rename so you could compare what happened)
19:32 < gwillen> I had updated, I will pin back to 1.31.1 using 'rustup override' and try again
19:32 < gwillen> I don't see any reason to expect different results, though
19:33 < gwillen> it still errors out
19:34 < elichai2> Really? Weird. I tried also in my vm, no errors in my machine, getrandom isn't even in the Cargo.lock anymore, tried deleting and recloning :O
19:34 < gwillen> uh, hm
19:35 < gwillen> do you still have "rand" 0.7.0 showing up?
19:35 < gwillen> (it has getrandom as a dependency)
19:37 < elichai2> no. that's the thing. we have no dependency that relys on rand 0.7
19:37 < elichai2> it looks to me like a glitch
19:38 < elichai2> rust-secp on version 0.12 used rand 0.4, and on version 0.15 rand 0.6
19:39 < elichai2> Found the problem!
19:39 < elichai2> it was actually tempfile
19:39 < gwillen> oh?
19:39 < elichai2> https://crates.io/crates/tempfile
19:39 < elichai2> they released a new version
19:39 < elichai2> and yanked it
19:39 < elichai2> and turned it into a major
19:39 < elichai2> loool
19:40 < gwillen> oh, yes, I see
19:40 < gwillen> I was thrown off by the fact that rand shows up twice
19:40 < elichai2> I started thinking i was going crazy heh
19:40 < gwillen> I didn't notice it was in there at two different versions
19:40 < gwillen> not sure why I'm not getting the new version of tempfile, there's probably a cache somewhere
19:41 < elichai2> yeah that's how I figured it out I saw rand 0.6.5 and then I looked who uses that and it was tempfile, looking at crates.io I immediately saw the yanked version
19:41 < elichai2> gwillen: probably
19:41 < gwillen> good that they were on top of it I guess
19:42 < gwillen> huh, the yanked version was replaced fully a month ago
19:42 < gwillen> I wonder why I am still getting it, and why you were but then it updated
19:46 < elichai2> Huh I didn't notice it was a month ago. Weird.
19:46 < elichai2> What tempfile version you have in your cargo.lock?
19:47 < elichai2> (if you could pastebin me that file that would be awesome)
19:47 < elichai2> It might still be a glitch in cargo
19:48 < gwillen> hmm, I have tempfile 3.1.0
19:48 < gwillen> are you getting 3.0.8?
19:48 < elichai2> Yes
19:49 < elichai2> So that's a semver glitch
19:49 < elichai2> Please keep a copy of your cargo.toml and cargo.lock, I might want to ask someone from the cargo workgroup about this
19:49 < gwillen> here's my cargo.lock https://pastebin.com/aTccAiqF
19:50 < gwillen> can you explain why you think it's a glitch
19:50 < gwillen> and what you think is going on
19:50 < gwillen> it says bitcoin depends on tempfile, but I don't immediately know how to check what version bitcoin thinks it wants
19:50 < gwillen> it's possible I have bitcoin at a weird version or something
19:51 < gwillen> there's my cargo.toml: https://pastebin.com/PHNx01Wv
19:51 < elichai2> Oh my mistake. I was sure we were relying on 3.0 in dev-dependencies, but I see we rely on 3. So that's not a glitch
19:51 < elichai2> :/
19:52 < elichai2> that's not a semver violation
19:52 < gwillen> ahhhh
19:52 < gwillen> I wonder why you are suddenly getting 3.0.8 then, when 3.1 would be the obvious choice
19:52 < elichai2> idk
19:52 < elichai2> I'll open a PR to lock those versions
19:52 < gwillen> in theory each version knows what rustc version it's compatible with, right?
19:52 < gwillen> so in theory you should get 3.0.1 if you're on a rustc not supported by 3.1
19:52 < gwillen> 3.0.8*
19:53 < gwillen> in which case it's not clear why I'k nmot
19:53 < elichai2> no. you can't specify a rust compiler in the version
19:53 < elichai2> afaik
19:53 < gwillen> I mean it does specify, I don't know how that's enforced
19:54 < gwillen> take a look at https://github.com/Stebalien/tempfile/commit/27315180e8fa1c9205d712602300fc94a68f178f
19:54 < gwillen> where they bump the version of rustc to 1.32.0 when bumping the version of tempfile
19:54 < gwillen> ohhh that's for travis, ok
19:54 < elichai2> yeah they bump the travis and the version they say in the readme
19:54 < gwillen> so it's not enforbed by cargo
19:55 < elichai2> I don't know of any mechanism in cargo/crates.io to enforce something like that
19:55 < gwillen> *nods*
19:59 < elichai2> it's still weird that even though 3.1.0 was released a month ago it's only happening now
20:00 < gwillen> it seems like it is nondeterministic somehow, which version it gets, which is odd
20:01 < gwillen> I assume that's not intentional nondeterminism in cargo
20:03 < elichai2> this should hopefully solve this https://github.com/rust-bitcoin/rust-bitcoin/pull/305
20:03 < elichai2> gwillen: it is weird
20:04 < gwillen> I'm not sure what the cargo policy on determinism is when there's no lockfile
20:05 < elichai2> gwillen: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
20:06 < gwillen> I don't see any commentary on determinism either way there
20:06 < elichai2> Oh determinism you're right I don't think there's an official policy
20:07 < elichai2> But it would be really weird
20:07 < gwillen> if the dependency tree is chased in no particular order, even if it takes the latest compatible version at every step, the final result could easily be nondeterministic
20:07 < gwillen> e.g. if it's using hashtables anywhere, iteration order would be potentially nondeterministic
20:08 < gwillen> it might not be obvious that algorithmic nondeterminism leads to a nondeterministic result, depending on what the possible solution set of a given project's dependency graph looks like
20:15 < elichai2> The weird thing is that I saw those errors. And they just disappeared and I can no longer see them
20:16 < gwillen> that strongly points to nondeterminism
20:16 < gwillen> I wonder if I retried a few times if I could get it both ways also
20:17 < elichai2> I saw them both on 1.33 and 1.22 but now i can't see them anywhere, I retried more than 20 times
20:17 < gwillen> or if cacheing mostly will prevent it unless you get unlucky
20:17 < elichai2> Including different OS
20:17 < gwillen> I am on OS X for the record
20:17 < gwillen> it seems maybe worth making a report to cargo
20:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
--- Log closed Mon Aug 05 00:00:30 2019