--- Log opened Wed Nov 27 00:00:20 2019 00:55 -!- jonatack [~jon@37.172.19.142] has joined #rust-bitcoin 01:09 -!- TamasBlummer [~Thunderbi@p200300DD671264219D69360EED605E75.dip0.t-ipconnect.de] has joined #rust-bitcoin 01:27 -!- dongcarl[m] [dongcarlca@gateway/shell/matrix.org/x-xccexqodgkurfkgg] has quit [Write error: Broken pipe] 01:41 -!- nijynot [~nijynot@83-233-23-98.cust.bredband2.com] has joined #rust-bitcoin 02:22 -!- dongcarl[m] [dongcarlca@gateway/shell/matrix.org/x-jrmyfdqrswvnadxd] has joined #rust-bitcoin 02:22 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-nsoeckcshcuxbdsg] has joined #rust-bitcoin 02:38 -!- dr_orlovsky [~dr-orlovs@2a02:1205:500f:2e90:945d:41d:a690:8c28] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 03:54 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has joined #rust-bitcoin 05:08 -!- jonatack [~jon@37.172.19.142] has quit [Read error: Connection reset by peer] 05:43 -!- jonatack [~jon@37.172.19.142] has joined #rust-bitcoin 06:25 -!- jonatack [~jon@37.172.19.142] has quit [Read error: Connection reset by peer] 06:25 -!- jonatack [~jon@37.172.19.142] has joined #rust-bitcoin 06:27 -!- jonatack [~jon@37.172.19.142] has quit [Read error: Connection reset by peer] 07:15 -!- jonatack [~jon@37.170.114.135] has joined #rust-bitcoin 07:54 < elichai2> Just found out I screwed up the implementation of the Context trait in rust-secp256k1 :/ 07:54 < elichai2> it should've been marked unsafe 07:56 < elichai2> in screwed up I mean a user can do `Context::deallocate(ptr::null::<[0u8;0]>() as *mut [u8])` and make safe rust dereference a null pointer 08:00 < elichai2> evalr: fn deallocate(ptr: *mut [u8]) {let _ = Box::from_raw(ptr);} deallocate(std::ptr::null_mut::<[u8:0]>() as *mut [u8]) 08:00 -evalr:#rust-bitcoin- error: unmatched angle bracket 08:00 -evalr:#rust-bitcoin- ~~~ Full output: https://play.rust-lang.org/?gist=79483bc77c70403754675b58c610db05&version=stable&mode=debug 08:01 < elichai2> evalr: fn deallocate(ptr: *mut [u8]) {unsafe{let _ = Box::from_raw(ptr);}} deallocate(std::ptr::null_mut::<[u8;0]>() as *mut [u8]) 08:01 -evalr:#rust-bitcoin- () 08:02 -!- nijynot [~nijynot@83-233-23-98.cust.bredband2.com] has quit [Ping timeout: 250 seconds] 08:04 < elichai2> evalr: fn deallocate(ptr: *mut [u8]) {unsafe{let _ = Box::from_raw(ptr);}} deallocate(5usize as *mut [u8; 50] as *mut [u8]) 08:04 -evalr:#rust-bitcoin- timeout: the monitored command dumped core 08:04 -evalr:#rust-bitcoin- ~~~ Full output: https://play.rust-lang.org/?gist=aae5e08f9c9e2ab56738070c3e1e2587&version=stable&mode=debug 08:04 < elichai2> yep. the deallocate function right now isn't marked as safe and can easily cause a core dump in safe rust 08:09 -!- Isabelle46Collie [~Isabelle4@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin 08:11 < elichai2> hmm I can just totally hide the Context trait but it might be a bit weird 08:14 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #rust-bitcoin 08:14 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host] 08:14 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin 08:16 < elichai2> that's how it will look like: https://elichai.github.io/test-secp256k1-docs/secp256k1/struct.Secp256k1.html 08:33 < andytoshi> has anyone looked into the webasm travis failures lately? 08:33 < andytoshi> sorry i've been AWOL so much. my server is back to crashing every day and i have a cronjob which only hard-resets it every morning (and then i have to manually start irssi) 08:35 < stevenroose> Could I get some extra eyes/ACKs on sepc256k1-sys? https://github.com/rust-bitcoin/rust-secp256k1/pull/169 08:39 < elichai2> andytoshi: trying now 08:40 < elichai2> yep. works on stable, crashes on beta 08:40 < elichai2> and I think I know why 08:40 < elichai2> I think the llvm version was bumped 08:40 < andytoshi> ah interesting elichai2 . frustrating 08:41 < elichai2> andytoshi: apparently it was fixed lately https://github.com/rust-lang/rust/commit/2bf59bea481dd4b4365cafe2e94fa8bf330a6877 08:42 < elichai2> should we make a matrix that both fuzz and wasm will run in parallel on stable? I hate travis matirxes 08:45 < andytoshi> elichai2: sure 08:45 < andytoshi> i think that's reasonable, nobody (incl webasm people) are likely to be using beta.. 08:54 < elichai2> andytoshi: what do you think? https://travis-ci.org/elichai/bitcoin_hashes/builds/617814089 08:54 < elichai2> I seperated fuzzing and wasm to their own tasks 08:55 < elichai2> arghh my syntax was bad 08:56 < andytoshi> stevenroose: still having trouble running your contrib script 08:57 < andytoshi> patching file secp256k1/include/secp256k1.h 08:57 < andytoshi> Reversed (or previously applied) patch detected! Assume -R? [n] 08:57 < andytoshi> Apply anyway? [n] y 08:57 < andytoshi> Hunk #1 FAILED at 202. 08:57 < andytoshi> (a bunch more Hunk FAILED lines) 08:57 < andytoshi> patch: **** Can't reopen file secp256k1/include/secp256k1.h : No such file or directory 08:58 < andytoshi> then git status shows a ton of files have been deleted and a bunch of .rs files have been added in the depend/ tree 08:59 < elichai2> did you run it with `./vendor-libsecp.sh depend` 08:59 < elichai2> the word depend is important 09:00 < andytoshi> yes. it won't even run without that 09:00 < elichai2> idk I had problems running it too because I tried to be smart and not read the markdown file lol (so I used `.`) 09:00 < andytoshi> lol 09:03 < elichai2> seems to work now :) https://travis-ci.org/elichai/bitcoin_hashes/builds/617816407 09:03 < elichai2> added the same caching machinasim for the cargo web I did in rust-secp and now i'll PR 09:04 < andytoshi> ok dope 09:07 < elichai2> https://github.com/rust-bitcoin/bitcoin_hashes/pull/66 09:28 < andytoshi> is anyone out there using rust-bitcoin in a browser or from a node app? 09:29 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:5c04:89ce:9939:6587] has joined #rust-bitcoin 09:29 < elichai2> not that I know of. I did it a few times locally though 09:30 < elichai2> https://github.com/rust-bitcoin/rust-lightning/pull/377#issue-310564496 https://github.com/elichai/rust-lightning/tree/wasm/wasm-test 09:35 < BlueMatt> andytoshi: no, I think mostly the only reason we added those tests is in the hope that we wont break it in the future, mostly from a "is our code nice and platform-independant, for code hygine's sake" pov 09:36 < elichai2> BlueMatt: A rebase should now make your PR mergable 09:36 < elichai2> https://github.com/rust-bitcoin/bitcoin_hashes/pull/65 09:36 < elichai2> BlueMatt: and because it's cool :P 09:37 < andytoshi> hmm, what were https://github.com/rust-bitcoin/rust-bitcoin/pull/240 people doing that they were talking about dropping rust-secp? 09:38 < elichai2> seems like monero related things https://github.com/h4sh3d https://github.com/h4sh3d/monero-swap-lib 09:41 < elichai2> altough there might be something private 09:44 < andytoshi> hmmm 09:45 < andytoshi> yeah, that's all rust only 09:46 < andytoshi> wonder where the node code is 09:52 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 09:54 < stevenroose> andytoshi: whoops, I did something silly :) while changing the git url from git@github.com: to https, I changed it from using bitcoin-core/secp to rust-bitcoin/rust-secp :sweat_smile: 09:54 < stevenroose> fixed and rebased 09:54 < stevenroose> some macros were changed in in master, so merging broke 09:55 < stevenroose> elichai2: could you check and re-ack? 09:55 < elichai2> will do 09:55 -!- instagibbs_ [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 250 seconds] 09:56 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #rust-bitcoin 09:57 < andytoshi> stevenroose: lol!! 10:17 < andytoshi> still hunks failing etc 10:20 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Remote host closed the connection] 10:23 -!- ariard_ [~ariard@167.99.46.220] has quit [Ping timeout: 250 seconds] 10:24 -!- ariard [~ariard@167.99.46.220] has joined #rust-bitcoin 10:29 < andytoshi> never mind 10:30 < andytoshi> this is awesome :) 10:30 < andytoshi> stevenroose: BlueMatt: ok good to go on 169? (rust-secp-sys) 10:34 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #rust-bitcoin 10:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 10:49 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin 11:03 -!- narodnik [narodnik@gateway/vpn/privateinternetaccess/narodnik] has joined #rust-bitcoin 11:03 < narodnik> hello everyone 11:04 < andytoshi> hiya 11:14 < narodnik> hello andytoshi, this is amir (genjix) 11:17 < andytoshi> oh nice. welcome to #rust-bitcoin 11:22 < narodnik> thanks 12:00 < andytoshi> can we mere https://github.com/rust-bitcoin/rust-secp256k1/pull/154 ? 12:00 < andytoshi> elichai2: ? 12:00 < andytoshi> or should i wait for an ack from BlueMatt 12:00 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:5c04:89ce:9939:6587] has quit [Quit: Sleep mode] 12:02 < andytoshi> elichai2: will merge https://github.com/rust-bitcoin/rust-secp256k1/pull/179 if you fix the comment nit 12:02 < elichai2> I think it's good. as long as BlueMatt doesn't access the bool from multiple threads :P 12:02 < elichai2> +1 12:02 < andytoshi> sorry stevenroose we need to rebose https://github.com/rust-bitcoin/rust-secp256k1/pull/169 :) 12:03 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:5c04:89ce:9939:6587] has joined #rust-bitcoin 12:04 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:5c04:89ce:9939:6587] has quit [Client Quit] 12:06 < elichai2> andytoshi: fixed the nit 12:06 < andytoshi> thanks! 12:07 < elichai2> andytoshi: just to make sure you understood, #184 didn't hide the Context trait from the user. just made it impossible to implement on his types (and fixed the unsafe thing) 12:07 < andytoshi> nice, unit tests work in valgrind now 12:07 < andytoshi> i haven't tried that in some years.. 12:08 < andytoshi> elichai2: yep, understood 12:08 < andytoshi> my concern is that rust-secp-zkp wraps the context pointer in some super unsafe ways 12:08 < elichai2> +1 12:08 < andytoshi> and, i had thought, implemented our context traits on the new wrapped pointer so that they'd work with the original lib's functions 12:08 < andytoshi> but maybe not, actually, i don't think the context trait is powerful enough for that 12:08 < andytoshi> maybe it should be? 12:09 < elichai2> hmm it is but only together with Verification/Signing/All 12:10 < andytoshi> well, imagine that rather than having a Secp256k1 with C:Verification etc 12:10 < andytoshi> we had Secp256k1: Verification 12:10 < andytoshi> er, Verification+Context 12:10 -!- jonatack [~jon@37.170.114.135] has quit [Read error: Connection reset by peer] 12:11 < elichai2> oh hmm well verification depends on Context 12:11 < elichai2> you can't impl Verification without impl Context 12:11 < andytoshi> then we'd genericize over the whole context object, like have `impl C { fn sign(&self) {} }` etc 12:11 < andytoshi> right 12:11 < andytoshi> i'm just being conservative 12:12 < andytoshi> hmmm, the whole scheme that i have in mind here is super unsafe 12:12 < elichai2> yeah. i'm just saying that I think this is what we have now. i.e `impl C { fn sign(&self) {} }` == `Verification: Context... impl C { fn sign(&self) {} }` 12:12 < andytoshi> what we have now is `impl Secp256k1 {...}` right? 12:12 < andytoshi> like, you have to use the `Secp256k1` defined in the crate 12:13 < andytoshi> you can't make your own 12:13 < elichai2> ohhhh 12:13 < elichai2> now I understand what you're saying 12:13 < elichai2> yes 12:13 < elichai2> you're right 12:14 < andytoshi> so my thought was that rust-secp256k1-zkp could define its own context object, provide helper methods that give a rawptr to a ffi context object, and it would work with the original library's functions 12:14 < elichai2> yeah we probably could replace the `Secp256k1` with the context object by adding some more functions (i.e. `get_context_ptr() -> *mut ffi::Context`) 12:14 < andytoshi> but the result of that would be that we'd have a context object from one C lib (libsecp256k1-zkp) being passed to another one (libsecp256k1) 12:14 < andytoshi> which might be illegal even in C 12:14 < andytoshi> s/illegal/UB/ 12:14 < elichai2> yeah hehe 12:15 < elichai2> and any change in the context struct in C might break everything here in a undefined way 12:15 < andytoshi> right, god forbid the two libraries' context objects diverged 12:15 < andytoshi> (actually, they used to diverge..) 12:16 < andytoshi> a long time ago we had another precomp table for the aux generator for pedersen commitments 12:18 -!- Isabelle46Collie [~Isabelle4@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds] 12:23 < elichai2> why don't you have it anymore? 12:23 < elichai2> sounds like a good idea heh 12:23 -!- michaelfolkson [~textual@host86-146-216-209.range86-146.btcentralplus.com] has joined #rust-bitcoin 12:26 < andytoshi> because with confidential assets we don't use a fixed generator anymore 12:26 < andytoshi> and also, the speedup wasn't -huge- 12:30 < elichai2> right because you need a generator per asset 12:32 < andytoshi> yep 12:34 -!- michaelfolkson [~textual@host86-146-216-209.range86-146.btcentralplus.com] has quit [Quit: Sleep mode] 12:39 < elichai2> I still hope one day the context could be const in the code. though I'm not sure how powerfull const expressions in C89 are (probabaly really not powerful lol) 12:40 < andytoshi> C has no notion of constness whatsoever 12:40 < andytoshi> it has a `const` keyword which makes a lot of things into compilation errors, many of which would have been programming mistakes 12:41 < andytoshi> but optimizations based on immutability of values, or pointer aliasing, can be done iff the compiler can prove they're valid ... and this has nothing to do with annotations that the programmer adds 12:41 < andytoshi> (this is why so much of rust's aliasing guarantees are disabled in LLVM btw ... no C compiler could provide them so they were never used and full of bugs) 12:42 < BlueMatt> andytoshi: sorry, just saw the fuzztarget change pr. I mean thats fine, yea, I dont think the race condition around setting a bool is worth worrying about :p 12:42 < andytoshi> yeah. i don't think that the fuzztester does anything multithreaded anyway 12:43 < BlueMatt> i mean even if it does 12:43 < BlueMatt> who cares :) 12:43 < elichai2> was `ptr.offset(N)` always unsafe fn? 12:43 < elichai2> I didn't remember that. weird. 12:43 < andytoshi> elichai2: i think so ... it can be UB in C to offset a pointer by the wrong amount 12:44 < elichai2> wait. ` wrapping_offset` is safe 12:44 < elichai2> wat 12:44 < andytoshi> o.O 12:44 < BlueMatt> right, just creating a pointer which you cannot dereference is UB 12:44 < BlueMatt> which is.....wtf 12:44 < BlueMatt> or something liek that 12:44 < elichai2> "Compared to offset, this method basically delays the requirement of staying within the same allocated object: offset is immediate Undefined Behavior when crossing object boundaries; wrapping_offset produces a pointer but still leads to Undefined Behavior if that pointer is dereferenced. offset can be optimized better and is thus preferrable in performance-sensitive code." 12:44 < andytoshi> lollll 12:44 < andytoshi> sounds like `wrapping_offset` actually does not offset the pointer until the time of dereference 12:45 < andytoshi> to simulate C not being batshit 12:46 < elichai2> it calls this intrinsic `pub fn arith_offset(dst: *const T, offset: isize) -> *const T;` 12:46 < BlueMatt> right i was just looking at the impl 12:46 < BlueMatt> I....dont quite fully understand this 12:46 < elichai2> I think it casts it to usize, add count*size_of:: and cast back 12:46 < elichai2> without checking anything 12:46 < elichai2> BlueMatt: yeah intrinsics suck 12:46 < BlueMatt> so you can cast a ptr to size_t then do math on it and its fine, then cast it back to a ptr and thats ok? 12:46 < BlueMatt> but its not ok to just do math on the ptr? 12:46 < BlueMatt> C is insane. 12:47 < andytoshi> hahaha 12:47 < andytoshi> that is consistent with my memory of the relevant parts of the language spec 12:47 < elichai2> https://github.com/rust-lang/unsafe-code-guidelines/issues/75 12:48 < elichai2> https://github.com/rust-lang/unsafe-code-guidelines/issues/205 12:50 < elichai2> BlueMatt: found it: https://github.com/rust-lang/rust/blob/master/src/librustc_codegen_llvm/intrinsic.rs#L234:L243 12:50 < elichai2> so no cast. they're both converted directly into llvm intrinsics 12:51 < BlueMatt> trololol 12:51 < elichai2> offset - LLVMBuildInBoundsGEP. arith_offset = LLVMBuildGEP 12:51 < BlueMatt> funny that LLVM has different intrinsics for this 12:53 < elichai2> yeah I wonder what's the actual difference 12:54 < BlueMatt> I'm sure in practice its identical, but some prover engine could use it I suppose 12:55 < elichai2> I'm deep in llvm's code to check right now lol 12:56 < elichai2> a hell of a lot of logic just to offset a pointer :O 12:56 < andytoshi> wouldn't surprise me if this is actually used in loop optimizations when iterating over array 12:56 < BlueMatt> ohhhh, yea, its probably for sse 12:57 < BlueMatt> like, if you follow the rules that pointers must be dereferenceable, you can sse load shit and throw it away if you dont need it 12:57 < BlueMatt> if you're unsure, you may have to serialize or so 12:59 < elichai2> yep they're the same 12:59 < elichai2> https://llvm.org/doxygen/Constants_8h_source.html line 1189 12:59 < elichai2> in the end getInBoundsGetElementPtr calls getGetElementPtr 13:00 < elichai2> altough there's so much overloading going on here with the same name but different amount of variables that it's hard to figure out 13:01 < elichai2> andytoshi: how should I call the unsafe variant of the ecdh? the same but with `_unsafe`? or `_unchecked`? or something else? 13:04 < stevenroose> andytoshi: secp-sys rebased 14:04 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has quit [Read error: Connection reset by peer] 14:05 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has joined #rust-bitcoin 14:16 -!- jonatack [~jon@37.167.197.45] has joined #rust-bitcoin 14:25 -!- TamasBlummer1 [~Thunderbi@p200300DD671264359D69360EED605E75.dip0.t-ipconnect.de] has joined #rust-bitcoin 14:27 -!- TamasBlummer [~Thunderbi@p200300DD671264219D69360EED605E75.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 14:27 -!- TamasBlummer1 is now known as TamasBlummer 15:12 -!- narodnik [narodnik@gateway/vpn/privateinternetaccess/narodnik] has quit [Remote host closed the connection] 15:13 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 246 seconds] 15:20 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 260 seconds] 15:21 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has joined #rust-bitcoin 15:53 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:b836:abdc:a37:9e09] has joined #rust-bitcoin 16:20 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:b836:abdc:a37:9e09] has quit [Ping timeout: 246 seconds] 19:28 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 19:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 21:49 -!- Netsplit *.net <-> *.split quits: wraithm 21:55 -!- Netsplit over, joins: wraithm 22:13 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 22:14 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #rust-bitcoin 23:31 -!- reallll is now known as belcher --- Log closed Thu Nov 28 00:00:21 2019