--- Log opened Thu Jan 09 00:00:04 2020 01:14 -!- mryandao_ is now known as mryandao 01:26 -!- CjS77 [~caylemeis@195.159.29.126] has joined #rust-bitcoin 01:48 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds] 02:14 < stevenroose> It seems like Cargo somehow broke support for adding features in dev-dependencies. The test code can't access secp's rand dep anymore 02:51 < elichai2> stevenroose: test code of what? 02:54 < stevenroose> look here: https://github.com/rust-bitcoin/rust-bitcoin/pull/380 02:55 < stevenroose> I've been looking into this for 30 minutes now getting any wiser 02:55 < stevenroose> Somehow suddenly the rand content of secp is gone. I checked rand v0.6.5 and nothing suspicous is there, it has both types that we're trying to use. 02:55 < stevenroose> Also nothing has changed to secp's rand definition. 02:58 < stevenroose> elichai2: any idea? 02:59 < elichai2> weird. try to look at the lock file? i'll test myself after fixing emscripten test here: https://github.com/rust-bitcoin/bitcoin_hashes/pull/71 03:01 < stevenroose> the lock file just shows rand v0.6.5. which it has been doing for a long time. Rand is at v0.7 now, but I really don't feel like updating that. I actually feel like secp should evne expose it's rand dep becaues it's never used in public API. 03:02 < elichai2> we can't update it. it broke compatibility with 1.22 03:02 < stevenroose> I think I'm gonna have rust-bitcoin depend on rand directly for tests. That means we'll have to change the rand feature name to use-rand, though. Because somehow dev-dependencies and features can't have the same name 03:03 < elichai2> lol, I know the problem 03:03 < elichai2> https://github.com/rust-bitcoin/rust-secp256k1/pull/176 03:04 < elichai2> that's all. just change to `rand-std` 03:04 -!- Haleigh66Mills [~Haleigh66@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin 03:04 < elichai2> I knew it's not that because it didn't complain about `secp256k1::rand` it complained about `thread_rng`. meaning `rand` was there but missing 03:04 < elichai2> *but missing parts 03:05 < stevenroose> Yeah I also realized the rand dep was actually existing. 03:05 < stevenroose> But, do you agree that secp shouldn't expose it's rand crate? 03:05 < stevenroose> It's never used in public API. So that means that updating the rand dep to a new major version is a breaking change to secp. 03:05 < elichai2> it is 03:06 < elichai2> https://docs.rs/secp256k1/0.17.1/secp256k1/struct.Secp256k1.html#method.generate_keypair 03:07 < stevenroose> ah damn, missed that. so you need to provide your own random 03:07 < elichai2> yep 03:07 < stevenroose> k, then just rand-std 03:07 < elichai2> theoretically we could replace with `rand_core` 03:08 < elichai2> but it can make it even more complex :( because `rand` and `rand_core` should match. which is stupid. the whole point of a "trait crate" is exactly that it doesn't have majors 03:08 < elichai2> arghh 03:08 < elichai2> I hate `rand` so much lol 03:09 -!- Haleigh66Mills [~Haleigh66@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 260 seconds] 03:09 < stevenroose> :D 03:10 < stevenroose> k pushed 03:32 -!- jonatack [~jon@atoulouse-656-1-807-188.w86-221.abo.wanadoo.fr] has joined #rust-bitcoin 03:41 -!- jonatack [~jon@atoulouse-656-1-807-188.w86-221.abo.wanadoo.fr] has quit [Ping timeout: 268 seconds] 03:41 -!- jonatack [~jon@134.19.179.179] has joined #rust-bitcoin 03:48 < elichai2> We're missing `fuzztarget` test in secp so we broke it without noticing :( 03:48 < elichai2> *in the CI 03:49 < elichai2> i'm thinking of just removihng the `cargo build` ones and replacing with `cargo test` because the build doesn't get to linking which means it's useless in checking FFI things 04:04 < stevenroose> elichai2: are you doing that or should I? 04:04 < elichai2> I'll do it 04:04 < elichai2> it will require a secp bump though :/ 04:05 < elichai2> BlueMatt: should the `fuzztarget` just not compile libsecp? 04:05 < elichai2> I think I won't place the right `link` there but just create local statics that makes sense 04:07 < stevenroose> elichai2: replacing the builds with tests in secp doesn't wokr because tests need std and the builds there all are without std. 04:07 < elichai2> what do you mean? 04:07 < stevenroose> So just changing the fuzztarget build with a test should be sufficient 04:08 < stevenroose> elichai2: in the secp travis, all `cargo build`s are with `--no-default-features` to test std-less-ness 04:08 < stevenroose> And the `cargo test` commands are all with std because the unit tests all need std. There is a special `no_std_test` executable to test no-std. 04:08 < elichai2> argh right. 04:09 < elichai2> altough `cargo build --verbose --features=fuzztarget` :( 04:09 < stevenroose> yeah so just changing that one to test should work 04:09 < elichai2> so apparantly rust doesn't support null in function pointers 04:17 < elichai2> so I guess we need to just fix the links unless we want to write more crap 04:24 < stevenroose> elichai2: unsafe null also not? (not knowing what is the case here but I'm not against unsafe if we're fixing fuzztarget tests) 04:25 < elichai2> it's instant UB 04:33 < elichai2> https://rust-lang.github.io/unsafe-code-guidelines/layout/function-pointers.html#representation 04:34 < elichai2> "However, null values are not supported by the Rust function pointer types -- just like references, the expectation is that you use Option to create nullable pointers. Option Ret> will have the exact same ABI as fn(Args...) -> Ret, but additionally allows null pointer values." 04:35 < stevenroose> elichai2: but how did the new symbols break this actually? 04:35 < elichai2> missing `link_name`. ie: https://github.com/rust-bitcoin/rust-secp256k1/blob/master/secp256k1-sys/src/lib.rs#L141 04:36 < elichai2> here: https://github.com/rust-bitcoin/rust-secp256k1/blob/master/secp256k1-sys/src/lib.rs#L447:L451 04:36 < stevenroose> If you grep for that symbol, rustsecp256k1_v0_1_1_context_no_precomp, it is defined in the depends.. 04:37 < stevenroose> rustsecp256k1_v0_1_1_ecdh_hash_function_default as well 04:37 < elichai2> look at the second link 04:37 < elichai2> there's no `link_name` attribute 04:38 < stevenroose> aaah yeah I noticed the fuzztarget exclue 04:39 < stevenroose> We can just update those, no? 04:39 < elichai2> I hoped I can remove them 04:40 < elichai2> there are possiblities for subtle UB there too :/ because the fuzztarget actually derefrences the Context struct 04:41 < stevenroose> elichai2: are you talking about what happens when you fix the link_names: free(): invalid pointer 04:41 < stevenroose> tbh I have no idea what the fuzztarget stuff even does 04:41 < elichai2> I'm talking about `pub static secp256k1_context_no_precomp: *const Context;` which links to the C code 04:41 < stevenroose> Shouldn't it be a dump no-op style impl of the API? 04:41 < elichai2> actually me too, I just read the code :) 04:42 < elichai2> I mean I read the code to see what it does, still don't know *what's the point* 04:42 < elichai2> but it does `(*cx).0` a couple of times, meaning it's dereferencing the pointer 04:42 < stevenroose> Yeah it somehow tries to avoid the allocation of the context 04:42 < elichai2> but `secp256k1_context_no_precomp` is a pointer to an entirely different struct, so there might be UB there. idk. 04:43 < stevenroose> But couldn't that be done by just having a fuzztarget alternative of the Rust code where the FFI is called instead? 04:43 < stevenroose> Like a Secp256k1::new() that works for all tags and is a no-op in the fuzztarget case? 04:43 < elichai2> exactly. that's what I wantted to do 04:43 < elichai2> oh hmm you mean not calling the ffi? or replacing the ffi? 04:43 < stevenroose> Sounds like there must have been a reason to do is the way it's done here 04:44 < stevenroose> elichai2: I mean removing all fuzztarget ffi code and just not calling ffi on fuzzdummy 04:44 < stevenroose> in fuzztarget* 04:44 < elichai2> right. but for some reason that code does *something* so I really don't know what's the purpose of it 04:45 < stevenroose> I also don't know what level of functionality is expected from the whole crate in fuzztarget mode 04:46 < stevenroose> should it do nothing (sig creation is zeroes/random and verification always true) or some basic stuff that's not crypto safe (like sig creation is the just summing pubkey and message hash and verification is trivial)? 04:48 < stevenroose> That's fun actually :D privkey -> pubkey could be XOR with some random global value or f.e. 010101010101, sig creation is priv XOR message and verification is then checking if pub XOR 01010101 XOR message == signature :D 04:49 < stevenroose> andytoshi, nickler: ^ does anyone of you know what the secp fuzz code is trying to achieve? 04:50 < elichai2> well pubkey create just does the privkey twice: https://github.com/rust-bitcoin/rust-secp256k1/blob/master/secp256k1-sys/src/lib.rs#L688 04:51 < elichai2> and signs uses msg32||privkey as the sig 04:55 -!- jonatack [~jon@134.19.179.179] has quit [Ping timeout: 260 seconds] 04:56 < elichai2> https://github.com/rust-bitcoin/rust-secp256k1/pull/191 04:58 < elichai2> btw, there are 2 tests in `secp256k1-sys` that will never get run on the CI because we never execute `cargo test` on `secp256k1-sys` :/ 05:01 < elichai2> how do people feel about moving the ci tests to python? I would've done bash but I want to use permutations to generate all possible feature sets. which is easy in python but quite hard in bash 05:25 < stevenroose> elichai2: haha the unit tests of course fail for fuzztarget :D 05:26 < stevenroose> If we want to execute linking perhaps we need to use cargo test xxx 05:31 < elichai2> right. damn it 05:37 < stevenroose> elichai2: so let's wait for andytoshi and/or nickler to give us some insight in the fuzztarget ffi code. Perhaps we can drop most of it eventually. 06:04 -!- takinbo [~takinbo@unaffiliated/takinbo] has quit [Quit: takinbo] 06:06 -!- takinbo [~takinbo@unaffiliated/takinbo] has joined #rust-bitcoin 06:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 06:09 < stevenroose> elichai2: can you push the fix for the fuzztarget test? 06:10 < elichai2> stevenroose: you mean without adding the test? ie https://github.com/rust-bitcoin/rust-secp256k1/pull/191 06:10 < stevenroose> yeah that but with the fix `cargo test --features fuzztarget xxx` 06:11 < stevenroose> so that it doesn't actually execute any tests using the fuzztarget (they obviously fail) but so that linking is tested 06:14 < elichai2> I think i'll do `cargo test --no-run --features=fuzztarget` 06:17 < stevenroose> haha yeah that works too! 06:20 < stevenroose> elichai2: you seem to have a typo in your last commit 06:20 < stevenroose> two list elements are placed on the same line 06:20 < elichai2> ops. thanks 06:21 < stevenroose> No worries :) 06:21 < elichai2> do you have permissions on travis? feel free to cancel all those fail commits lol 06:22 < stevenroose> It's been about a month since I had the secp symbol collision fixed locally towards a rust-bitcoin release :) Still pretty fast of course for any software release cycle, but since we want to use releases inside our own projects, I'm anxious to get it in :) 06:22 < stevenroose> elichai2: IIRC force pushed auto cancel previous jobs of the same PR, no? 06:22 < elichai2> Or I'll just check on my travis heh 06:22 < elichai2> pretty sure no 06:22 < elichai2> well we also broke bitcoin_hashes 06:23 < elichai2> https://github.com/rust-bitcoin/bitcoin_hashes/pull/71 06:32 < elichai2> passes except emscripten 06:34 < andytoshi> stevenroose: elichai2: the rust-secp fuzztest code is ancient 06:35 < andytoshi> it can be dropped. it was an experiment that predates honggfuzz 06:35 < elichai2> completely dropped? there's no need for any fuzzing code there? 06:35 < andytoshi> completely dropped yes 06:35 < stevenroose> nice 06:35 < andytoshi> we probably should write some "real" fuzz code at some point :) 06:35 < andytoshi> but it's not a -huge- priority since the underlying C library has been fuzzed to hell 06:36 < andytoshi> but it would definitely be good to do, and would engender goodwill with upstream if we were to fuzz their stuff in our CI 06:36 < stevenroose> elichai2: you doing a PR to drop all of it? I can try do it as well 06:36 < stevenroose> andytoshi: I was mostly worried about rust-bitcoin f.e. using secp while fuzzing 06:36 < andytoshi> so, rust-bitcoin does use the fuzztarget feature 06:36 < stevenroose> without a secp fuzz target it might be doing real operations 06:36 < andytoshi> that is useful and important 06:37 < stevenroose> andytoshi: wait you mean dropping fuzz test code in rust-secp or dropping the fuzztarget feature? 06:37 < stevenroose> we were talking about the latter 06:37 < andytoshi> oh 06:37 < andytoshi> don't do that 06:37 < andytoshi> let me read the scrollback 06:38 < stevenroose> somehow the rust secp fuzztarget is doing some magic in the FFI 06:38 < stevenroose> and we were wondering why, why it couldn't reimplement Rust things without using the FFI evne 06:38 < andytoshi> it probably could 06:39 < andytoshi> i suspect any use of FFI in fuzztarget is because we (matt and i) were being lazy 06:39 < andytoshi> and trying to minimize how much extra fuzztarget code we were writing 06:39 < elichai2> I actually like that it doesn't touch the main code 06:40 < stevenroose> :D 06:40 < stevenroose> well, what's our strategy for fixing it? :) just your quick fix then? 06:41 < andytoshi> tl;dr the quick fix? i need to pay attention to the current talk 06:42 < stevenroose> just fixing some symbol names 06:42 < stevenroose> https://github.com/rust-bitcoin/rust-secp256k1/pull/191/ 06:42 < stevenroose> elichai2: there seems to be an issue with an emscripten test now 06:42 < andytoshi> thanks 06:42 < elichai2> andytoshi: i'll do a recap. the reason we're talking about this is that `fuzztarget` is actually not linking rn 06:43 < elichai2> stevenroose: yep. seems to be a problem in rust 1.40 https://github.com/rust-lang/rust/issues/68055 06:43 * elichai2 facepalm 06:43 < andytoshi> lol 06:46 < stevenroose> ok I'll just ACK it then, it seems like the fuzztarget test passes 06:46 < andytoshi> pls let me take a look before merging 06:46 < elichai2> +1 06:46 < stevenroose> elichai2: eh you removed the rand test instead of putting it back on the line below :D 06:47 < stevenroose> I think initially you changed the cargo build with rand to cargo test with rand, but now you dropped it 06:47 < andytoshi> so, first off, in the diff why is there a hardcoded version in the link symbol 06:47 < elichai2> opff 06:47 < andytoshi> also that - the test is removed in travis :) 06:48 < elichai2> because these are the new symbols? https://github.com/rust-bitcoin/rust-secp256k1/blob/2e3fa772d3046861164b2168a1ed7bc76ae54f9f/secp256k1-sys/src/lib.rs#L139 06:48 < andytoshi> elichai2: so, those are machine generated 06:48 < andytoshi> even though they're committed 06:48 < elichai2> ha. really? 06:48 < andytoshi> yeah, in secp256k1-sys/vendor-libsecp.sh 06:49 < andytoshi> so you'll need to modify the script to generate your new code 06:49 < andytoshi> then run the script 06:49 < andytoshi> then commit the result :P 06:49 < elichai2> ok. I think the script only *updates* the links. not create them 06:49 < andytoshi> oh! ok then maybe this is ok 06:49 < elichai2> so i'll change to an old versions and run it to make sure it updates 06:50 < elichai2> and commit the result I guess 06:50 < andytoshi> kk thanx 06:50 < stevenroose> the script should corretly replace version prefixes yes 06:50 < stevenroose> as long as we keep using vXX_YY_ZZ format 06:50 < stevenroose> nothing exotic with beta or rc or so I didn't test that 06:50 < andytoshi> heh yeah we'll always use xx_yy_zz 06:52 < elichai2> does anyone knows the current libsecp revision? 06:52 < andytoshi> it's in a comment somewhere 06:52 < andytoshi> easiest is to just choose one, look at the resulting diff for commit ids 06:53 < elichai2> yep, here https://github.com/rust-bitcoin/rust-secp256k1/blob/master/secp256k1-sys/depend/secp256k1-HEAD-revision.txt 06:53 < andytoshi> nice 06:53 < elichai2> nice, worked 06:53 < elichai2> pretty cool :) 06:53 < andytoshi> yeah, thank stevenroose for that script :) 06:53 < elichai2> I changed the ver to 0_9_0. ran it and there's no diff now :D 06:53 < elichai2> stevenroose: Thanks! :) 06:54 < andytoshi> excellent 06:55 < elichai2> oh rightt I think I removed that travis line on purpose lol, because it was both building and testing with `std` features, I'll put it back 06:56 < stevenroose> welcome :) so let's do this :) once new secp minor is out, rust-bitcoin v0.23 should be good to go as well :) 06:56 < elichai2> andytoshi: how do you feel about python script for executing the tests? 06:56 < andytoshi> not thrilled 06:57 < elichai2> I want to use combinatorics to test every feature combination both on secp and on secp-sys 06:57 < elichai2> hmm 06:57 < andytoshi> ah nice 06:57 < andytoshi> no that's fine 06:57 < andytoshi> python for travis is fine 06:57 < elichai2> cool. because writing that in bash is hell lol 06:57 < andytoshi> lol yeah, definitely i'd prefer python to bash 06:57 < andytoshi> i also can't review bash :) 06:58 < elichai2> no one really can :P 06:58 < stevenroose> is scripting in Rust such a pain? 06:58 < stevenroose> we have the no_std_test thing already 06:58 < andytoshi> it's a bit of a pain because there's a compile step 06:58 < stevenroose> can just as well have combinatory_test similarly 06:58 < stevenroose> cargo run 06:58 < stevenroose> but yeah I know what you mean 06:59 < andytoshi> so, the no_std_test is there specifically to test cargo linking 06:59 < stevenroose> also the execution code will be harder to do 06:59 < andytoshi> it's not really a test runner 06:59 < elichai2> yep 06:59 < elichai2> someone should do something like Groovy but for rust 07:00 < elichai2> `contrib` vs `ci`? 07:00 < elichai2> (dir for the script) 07:00 < andytoshi> i think we shuold call it contrib 07:00 < andytoshi> that's more-or-less "standard" for weird scripts 07:00 < andytoshi> i also think the vendoring script should be in there,b but *shrug* 07:02 < stevenroose> elichai2: you want to do that for the next release? 07:03 < andytoshi> minor release right 07:03 < andytoshi> of rust-secp ? 07:03 < stevenroose> ah no, I see you fixed #191. andytoshi, could you also review? 07:03 < andytoshi> kk 07:03 < stevenroose> yes, it's just fuzztarget code that's needed for rust-bitcoin's fuzzing 07:04 < andytoshi> elichai2: no changes neededto the revendoring script/ 07:04 < andytoshi> ? 07:04 < elichai2> nope 07:04 < elichai2> just works as is 07:04 < andytoshi> dope 07:06 < andytoshi> elichai2: ok can you add a commit to 191 that bumps the minor version number 07:06 < andytoshi> utack 07:06 < andytoshi> good find on the --no-run flag 07:06 < andytoshi> for cargo test 07:07 < elichai2> FWIW if anyone cares about the download size `Crate Size 33.86 kB`(https://crates.io/crates/secp256k1) we can reduce that using somethinhg like: https://github.com/elichai/log-derive/blob/master/Cargo.toml#L12:L15 07:07 < elichai2> andytoshi: just read `cargo test --help` :) 07:08 < stevenroose> elichai2: does that mean that it's also not uploading the README, LICENSE and CHANGELOG to crates.io? Or is that just what crates includes into the tarball downloaded by cargo? 07:09 < elichai2> andytoshi: odne 07:09 < elichai2> done 07:10 < elichai2> stevenroose: Yes but they are still used by cargo in the `license` and `readme` attributes in cargo.toml 07:10 < andytoshi> ok utack. approved. will wait for travis 07:10 < elichai2> well it will fail on emscripten 07:10 < elichai2> but let's make sure it fails only on that 07:11 < andytoshi> oh ok 07:11 < andytoshi> do we need to update .travis.yml to not fail then? 07:11 < elichai2> hmm if we require it to pass then I guess yeah :/ 07:11 < andytoshi> lol well, i don't think i'll even get a merge button if travis fails :) 07:12 < elichai2> Can someone close #178 and #150? :) 07:13 < elichai2> andytoshi: argh, I'll just add ` || true` 07:13 < andytoshi> lol, on the emscripten test? 07:13 < elichai2> yeah 07:13 < andytoshi> only when doing fuzztarget? 07:14 < elichai2> emscripten generally doesn't work on latest stable 07:14 < andytoshi> because of your recent bug https://github.com/rust-lang/rust/issues/68055 07:14 < andytoshi> or in general? 07:14 < elichai2> because of that 07:15 < elichai2> seems to be known on nighly but then regressed to stable https://github.com/rust-lang/rust/issues/66916 07:15 < andytoshi> ok hm 07:15 < andytoshi> is this the only reason that we expect failures with 191? 07:15 < elichai2> you can tru yourself. it gives the same error on a hello world 07:15 < elichai2> yes 07:15 < andytoshi> oh ok 07:15 < andytoshi> never mind then i'll just force merge 07:16 < elichai2> andytoshi: wait for it to pass on all except stable: https://travis-ci.org/rust-bitcoin/rust-secp256k1/builds/634788560 07:16 < andytoshi> closed 178 and 150 .. thanks for the heads up stevenroose 07:16 < andytoshi> kk elichai2 07:24 < stevenroose> andytoshi: do you need another official ack on the PR? 07:24 < stevenroose> (I'm not in the rust-secp repo.) 07:25 < andytoshi> stevenroose: no, rust-secp only needs one ack 07:26 < andytoshi> because we have very few maintainers there :) i think it might be just me and matt and jonas 07:28 < andytoshi> ok, let me figure out how to merge this 07:29 < andytoshi> ok merged 07:30 < andytoshi> pubrished 07:30 < andytoshi> published 07:32 < andytoshi> kicked travis for rust-bitcoin 0.23 07:40 < stevenroose> nice! 07:41 < andytoshi> one sec, it's hung up 07:42 < andytoshi> cleared cache, restarted 07:49 < stevenroose> Shoot. I actually mentioned we should probably test the secp update first if it worked with rust-bitcoin. 07:50 < stevenroose> But I forgot as well. 07:55 < stevenroose> elichai2: it seems like the secp256k1_context_no_precomp that you created manually in the fuzz_dummy is not found 07:55 < stevenroose> elichai2: https://travis-ci.org/rust-bitcoin/rust-bitcoin/jobs/634689420?utm_medium=notification&utm_source=github_status 07:55 < elichai2> you're kidding me 07:56 < elichai2> wait, this makes no sense 07:59 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 08:02 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has joined #rust-bitcoin 08:03 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 08:03 < elichai2> stevenroose: that's because andytoshi released a secp ver instead of a secp-sys 08:03 < elichai2> my change was in the -sys crate 08:04 < elichai2> i'm sorry 08:04 < elichai2> I bumped the wrong crate 08:05 < andytoshi> lolll 08:05 < andytoshi> oops 08:05 < andytoshi> sorry 08:05 < andytoshi> can you PR to bump the -sys version 08:05 < elichai2> it's my mistake. I should've noticed when I bumped the "regular" one 08:05 < elichai2> lol 08:06 < elichai2> trying to decide what to do with the changelog now lol 08:06 < elichai2> at least it didn't do any hard 08:06 < elichai2> *harm 08:06 < andytoshi> i'd just delete the 0.17.2 entry :P 08:06 < elichai2> and we have no CHANGELOG for -sys ? 08:06 < elichai2> k, i'm just bumping the -sys 08:06 < andytoshi> i think it's ok to not have one since this is a bugfix 08:07 < andytoshi> and probably nobody would notice it except us 08:07 < elichai2> wait. does it mean I need to re-vendor? 08:07 < elichai2> because it's a new -sys? what are the rules here? re-vendoring for every minor or major? 08:07 < andytoshi> hmm good q 08:08 < elichai2> theoretically cargo doesn't allow 2 different minors in the same build 08:08 < elichai2> AFAIK 08:08 < andytoshi> right 08:08 < elichai2> it only allows 2 different majors 08:08 < elichai2> I think 08:08 < andytoshi> so i think it's ok to not bump the minor 08:08 < elichai2> too much mental juggling for this lol 08:08 < andytoshi> err, to not revendor 08:09 < andytoshi> i think we should treat the minor version in the vendor version as some sort of emergency thing 08:09 < andytoshi> that we shouldn't normally use 08:09 < andytoshi> because actually bumping it would change the link symbols which is arguably a breaking change 08:09 < elichai2> right 08:11 < elichai2> lol just wrote 08:11 < elichai2> accidentally opened before writing 08:12 < andytoshi> waiting on travis. will be 10-15 minutes :P 08:13 < elichai2> do we want to test all feature combinations with `--release`? 08:13 < andytoshi> yeah i think so 08:13 < elichai2> k 08:13 < elichai2> writing the py script 08:18 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has quit [Quit: Sleep mode] 08:24 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has joined #rust-bitcoin 08:38 < andytoshi> ok published 0.1.2 08:38 < andytoshi> kicked travis on rust-bitcoin 08:58 < stevenroose> worked! 08:58 < stevenroose> https://github.com/rust-bitcoin/rust-bitcoin/pull/380 09:00 < kanzure> are there any P2WSH transaction examples (setup and spend) in rust-bitcoin? 09:00 < andytoshi> alright let's get this fucker out the door 09:00 < andytoshi> elichai2: can you ack 09:00 < andytoshi> kanzure: not sure about examples ... but you can create an address with https://docs.rs/bitcoin/0.22.0/bitcoin/util/address/struct.Address.html#method.p2wpkh 09:01 < andytoshi> then call .script_pubkey() on that to get a script pubkey you can put in a tx 09:01 < andytoshi> then to sign, you want to use https://docs.rs/bitcoin/0.22.0/bitcoin/util/bip143/struct.SighashComponents.html 09:01 < andytoshi> create one of those from your transaction, then call .sighash_all() with the specific input you're signing, and it will give you a sighash 09:02 < andytoshi> if you need non-sighash-all it'd be appreciated if you can open an issue 09:02 < andytoshi> this is a multi-year TODO but somehow nobody has ever complained up til now 09:03 < andytoshi> merged #380 09:04 < andytoshi> published and pushed tag. thanks everyone! esp elichai2 stevenroose dr-orlovsky 09:05 < elichai2> ? ? 09:14 < stevenroose> yuuhuuw 09:14 < stevenroose> good work guys! 09:15 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 09:16 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #rust-bitcoin 09:33 < elichai2> good timing too. my weekend starts now :) 09:46 < elichai2> ~13 minutes and 250 cargo calls :) i'll PR the new script soon 09:50 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has quit [Quit: Sleep mode] 09:57 -!- michaelfolkson [~textual@host86-133-235-133.range86-133.btcentralplus.com] has joined #rust-bitcoin 10:09 < stevenroose> kanzure: wait I might have examples 10:10 < stevenroose> ah P2WSH, I don't think so, sorry. Just P2WPKH 10:14 < dongcarl> Any meaty feature requests I can try to do? 10:52 -!- michaelfolkson [~textual@host86-133-235-133.range86-133.btcentralplus.com] has quit [Quit: Sleep mode] 11:50 < stevenroose> dongcarl: script execution/verifiation? :D Would be fun to fuzz against rust-bitcoinconsensus 12:00 < andytoshi> miniscript can do script verification fwiw 12:00 < andytoshi> sanket1729 wrote a bunch of code for that 12:16 < stevenroose> andytoshi: I think it doesn't. I think it can only do miniscript verification or something. Plus performance. I remember hearing here that it wasn't really usable for generic script verification. 13:01 < andytoshi> yes, it can't be used to verify the blockchain ofc 13:01 < andytoshi> because it only supports miniscripts 13:02 < andytoshi> but it could certainly be used, at lesat initially, to fuzz the bitcoinconsensus script interpreter 13:48 < stevenroose> andytoshi: I was more interested in a full Rust reimplementation of execution and to find discrepancies between it and Core using rust-bitcoinconsensus. While it's probably extremely unlikely, it could discover some more unexpected behaviour on Core. 14:06 < andytoshi> ah makes sense 14:06 < andytoshi> yeah i think that'd be a super cool project 14:07 < andytoshi> but if dongcarl is looking for helpful things to do for rust-bitcoin ... :P 14:15 < dongcarl> andytoshi stevenroose It does sound pretty cool... I'd be down if there are no other missing features you guys can think of 14:19 < andytoshi> so, there is a list of TODO issues in rust-miniscript; in rust-bitcoin it would be good to add the rest of the hashtypes 14:20 < andytoshi> now that we have symbol name-collisions sorted out maybe nickler could use help on rust-secp256k1 14:20 < andytoshi> now that we have symbol name-collisions sorted out maybe nickler could use help on rust-secp256k1-zkp 14:27 < dongcarl> andytoshi: sounds good 14:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 14:29 < andytoshi> s/the rest of the hashtypes/the rest of the sighashtypes/ 14:29 < andytoshi> like, not just sighash_all 14:33 < dongcarl> andytoshi: sounds like a good refresher for me, will take a crack at it 14:40 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has joined #rust-bitcoin 14:47 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:a430:fcab:6567:f900] has quit [Quit: Sleep mode] 16:16 < andytoshi> heh, i also suggested instagibbs do this as a way to get up to speed with the project 16:16 < andytoshi> i should really go through and make a janitor-project list 19:16 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds] 19:19 -!- jonatack [~jon@88.124.242.136] has joined #rust-bitcoin --- Log closed Fri Jan 10 00:00:02 2020