--- Log opened Wed Dec 11 00:00:33 2019
00:39 < Kiminuo> https://github.com/rust-bitcoin/rust-bitcoin/pull/363
01:24 < Kiminuo> https://github.com/rust-bitcoin/rust-bitcoin/pull/364 - review, anyone?
02:21 < Aleru> ariard: ping :) couldn't help myself... i went ahead and opened a PR on the main repo with some information there... I probably should not have done that as its a work in progress?
03:13 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
03:17 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
03:34 -!- Arnoldo10Jaskols [~Arnoldo10@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin
03:47 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
03:50 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 260 seconds]
04:23 -!- ccdle12 [5eadef37@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
04:29 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:1914:fb42:1fcf:78f3] has joined #rust-bitcoin
04:35 -!- nijynot [~nijynot@h-177-96.A785.priv.bahnhof.se] has joined #rust-bitcoin
04:40 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:1914:fb42:1fcf:78f3] has quit []
05:08 -!- nijynot [~nijynot@h-177-96.A785.priv.bahnhof.se] has quit [Ping timeout: 240 seconds]
05:16 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin
06:28 < elichai2> andytoshi: I'm curious if you've given much thought to the design of schnorr signatures in the bindings
06:29 < elichai2> we will need a seperate publickey, signautre, partialsignature, and maybe even a seperate secretkey
06:29 < elichai2> *?
06:38 -!- Arnoldo10Jaskols [~Arnoldo10@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]
06:45 -!- reallll is now known as belcher
06:51 -!- Kiminuo [~mix@141.98.103.126] has quit [Ping timeout: 268 seconds]
07:00 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
07:01 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
07:49 < stevenroose> elichai2: ^
07:49 < stevenroose> Currently it specifies `links = "secp256k1"` which makes it impossible to link with other secp linkers. But since all those symbols are prefixed, should we change that to `links = "rustsecp256k1_v0_1_0"` like the prefix?
07:54 < stevenroose> https://github.com/rust-bitcoin/rust-secp256k1/pull/189
07:54 < stevenroose> andytoshi:
07:55 < stevenroose> I think that makes sense. I was trying to upgrade rust-bitcoin to new secp and collided with bitcoinconsensus. Obviously we should also update bitcoinconsensus, but the whole point of the -sys change was to not have that error anymore :)
07:58 < elichai2> Are you quoting andytoshi or asking him?
07:58 < elichai2> Try to remove the `links` from the toml
08:11 < stevenroose> elichai2: eh yeah we can just remove it
08:11 < stevenroose> would that be better?
08:12 < stevenroose> elichai2: If a manifest contains a links key, then Cargo supports overriding the build script specified with a custom library. The purpose of this functionality is to prevent running the build script in question altogether and instead supply the metadata ahead of time.
08:13 < stevenroose> we'd lose that, but I think we'd also lose that if we changed the links to something rust-secp specific
08:14 < stevenroose> This is what we get now in rust-bitcoin: the package `secp256k1` links to the native library `secp256k1`, but it conflicts with a previous package which links to `secp256k1` as well:
08:19 < stevenroose> https://github.com/rust-bitcoin/rust-secp256k1/pull/190 (alternative that removes the key)
08:31 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
08:43 -!- ccdle12 [5eadef37@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 260 seconds]
08:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin
09:22 < andytoshi> elichai2: nickler has been thinking about this
09:22 < andytoshi> well, about musig
09:23 < andytoshi> but i haven't really been following the upstream work wrt schnorr sigs ... yeah, i guess now that we have the xonly stuff we need a new pubkey type
09:23 < andytoshi> and probably we ought to have a distinct secret key type
09:23 < elichai2> It's upsetting that even the privkey type have a separate xonly add
09:23 < andytoshi> as for partial signatures, that falls under musig and we really need nickler's expertise :)
09:24 < elichai2> Yeah musig makes sense
09:24 < andytoshi> well morally the privkey ought to be different anyway
09:24 < andytoshi> stevenroose: good call about changing the "link =" line to have a prefix
09:24 < elichai2> Hmm I guess so
09:24 < elichai2> I'm writing now bindings for go including schnorr
09:25 < andytoshi> or removing it. i'd ack either one
09:25 < elichai2> And I hoped I could use the same privkey type but  nah
09:26 < elichai2> Oh changing to the prefix lol. That makes more sense
09:26 < elichai2> Didn't think of that
09:26 < stevenroose> elichai2: yeah I don't know which approach is better
09:26 < stevenroose> I don't have the most experience doing the more exotic linking work..
09:26 < elichai2> I think prefixing. That way we don't really change anything
09:26 < stevenroose> You or BlueMatt might have
09:26 < elichai2> Altough hmmm
09:26 < andytoshi> agreed about prefixing being better
09:26 < elichai2> If someone use the feature that disables the prefix
09:27 < elichai2> Than now everything is weird
09:27 < andytoshi> it seems that it gives us more features and also lets us conflict with e.g. rust-secp-zkp if it ever decides to share the same symbols for some reason
09:27 < stevenroose> elichai2: I think with prefixing, we kind of defeat the purpose of the field as explained here: https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key
09:28 < elichai2> Well we don't. Because the *right* symbols are with the prefix
09:28 < elichai2> At least unless you use the feature that changes that lol
09:28 < stevenroose> Yeah OTOH removing the links breaks it strictly more :D
09:28 < elichai2> Anyhow I don't know of anyone who uses that feature (the link attribute)
09:29 < stevenroose> It seems that ideally, we would have the links property conditional on the `external-symbols` feature, but that's not possible
09:29 < andytoshi> elichai2: i've been saved by our use of it before
09:29 < andytoshi> "saved by"
09:29 < elichai2> How?
09:29 < andytoshi> got a coherent error message instead of crazy linker shit
09:29 < elichai2> Ohh
09:29 < andytoshi> when i was trying to mix libraries that wolud've conflicted
09:29 < elichai2> That's nice
09:30 < stevenroose> Yeah but that's no longer needed with prefixed -sys.
09:30 < elichai2> Because they both used the *same* link attr?
09:30 < stevenroose> elichai2: yeah
09:30 < andytoshi> specifically when i was mixing an upstream rust-secp with a local copy that i'd modified.
09:30 < andytoshi> yeah
09:30 < elichai2> stevenroose: well you can still mix conflicting sys versions
09:30 < stevenroose> elichai2: no because -sys version don't conflic
09:30 < stevenroose> ah yeah you could locally edit one, sure
09:30 < elichai2> andytoshi: for that I try to use the patch attr
09:30 < stevenroose> but no 2 -sys releases that are correctly prefixed
09:31 < elichai2> Yeah so the C symbol makes this suck
09:31 < elichai2> Hmm
09:31 < elichai2> I think. That we can assume that only advanced users use that feature so the link attr should stay but with the prefix
09:32 < elichai2> And use cases like those might not even use cargo so don't care
09:32 < andytoshi> elichai2: ah, i should learn about patch attr
09:32 < andytoshi> i am still editing ~/.cargo/config like it's 2015
09:32 < stevenroose> Something totally different: anyone that can give orders of magnitude CPU times for a sha256 hash and EC signature verification (assume libsecp)?
09:32 < elichai2> Hehe yeah cargo got better in that
09:33 < andytoshi> stevenroose: on my laptop sha256 compression is ~200ns, sig verification is about 50us
09:33 < elichai2> 40us for ec ver
09:34 < stevenroose> Thanks :)
09:39 < stevenroose> So, I guess I vote for prefixed `links = ` :)
09:39 < stevenroose> If we can get secp v0.17.1 out within 30 minuts, I think I have time to make PRs for bitcoinconsensus and bitcoin
09:40 < stevenroose> I can make them for "0.17" which would automatically upgrade to 0.17 but then someone could accidentally have =0.17.0 and break his own project :)
09:40 < stevenroose> upgrade to 0.17.1*
09:44 < andytoshi> lol sure
09:44 < andytoshi> link to PR for 0.17.1?
09:47 < stevenroose> https://github.com/rust-bitcoin/rust-secp256k1/pull/189
09:48 < andytoshi> hahah 76 files changed
09:48 < elichai2> You didn't bump the actual version
09:48 < stevenroose> yeha just pushe dthat
09:48 < andytoshi> what is the command to recreate what you did?
09:49 < stevenroose> andytoshi: yeah you can verify by running the vendor script manually
09:49 < stevenroose> sorry
09:49 < stevenroose> ./vendor-libsecp.sh depend 0_1_1 143dc6e9ee31852a60321b23eea407d2006171da
09:49 < stevenroose> same upstream commit
09:50 < andytoshi> thanks got it
09:50 < elichai2> I'm on my phone so sadly I can't review this PR (as it requires running the vendor script heh)
09:50 < andytoshi> do we need to bump to 0.17.1?
09:50 < andytoshi> it's fine, i ran it, it ran clean
09:50 < stevenroose> by bumping secp proper one can ensure -sys 0.1.1 is used by requiring ~0.17.1
09:51 < stevenroose> not a biggy,willing to not do that if you prefer
09:51 < andytoshi> ah nice
09:51 < andytoshi> yeah, can you do that?
09:51 < stevenroose> remove the bump?
09:51 < stevenroose> andytoshi: ^
09:52 < andytoshi> no, enforce 0.1.1
09:52 < stevenroose> ah, yeha I pushed that a few minutes ago
09:52 < stevenroose> sorry
09:52 < andytoshi> i *think* what you did will not require 0.1.1?
09:52 < andytoshi> you need to use ^ or something
09:52 < andytoshi> i could be wrong
09:53 < andytoshi> eh, whatevr, i'll just merge as is
09:53 < andytoshi> this is a really minor thing
09:53 < stevenroose> "0.1.1" is quivalent to "^0.1.1" which is ">=0.1.1"
09:53 < andytoshi> ah yep i see
09:53 < andytoshi> but lol, travis is claiming that the secp-sys version wasn't bumped
09:55 < stevenroose> heh
09:55 < stevenroose> ah it isn't heh
09:55 < stevenroose> fixed, very strange. well I made two PRs might have messed up what I did in which :s sorry for the trouble
09:57 < stevenroose> let's wait for travis to confirm I didn't mess up even more
09:57 < andytoshi> lol sounds good
09:57 < stevenroose> might have to wait an hour or 2 before I can do downstream PRs, I'm waiting for a friend to pick me up here and he's unexpectedly early
09:57 < andytoshi> np
10:17 < andytoshi> ok published new secp and secp-sys versions
11:14 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Remote host closed the connection]
14:12 < stevenroose> What's the status of https://github.com/rust-bitcoin/rust-bitcoin/issues/284 review?
14:45 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
15:05 -!- Kiminuo [~mix@141.98.103.126] has joined #rust-bitcoin
16:19 -!- Kiminuo [~mix@141.98.103.126] has quit [Ping timeout: 250 seconds]
--- Log closed Thu Dec 12 00:00:34 2019