--- Log opened Fri Oct 18 00:00:38 2019
00:26 -!- jonatack_ [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined #rust-bitcoin
00:43 -!- jonatack_ [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Quit: jonatack_]
00:43 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined #rust-bitcoin
01:57 < elichai2> why are you using trait objects?
01:58 < elichai2> I kind of hate them honestlly. unless you know the binary is really bloated because of generics this is just memory overhead for a vtable
02:01 < belcher> BlueMatt :)
02:48 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
04:02 -!- willcl_ark [~quassel@95.211.225.220] has joined #rust-bitcoin
04:23 -!- jonatack [~jon@185.28.187.26] has joined #rust-bitcoin
04:26 < ariard> here for the workshop, let's meetup before the coffee bar in 30min!
05:14 < ariard> https://github.com/ariard/hacking-rust-lightning here the instruction!
05:25 < Ed0> Thank you ariard, we are maybe 6 following instructions :)
05:32 < ariard> https://github.com/TheBlueMatt/rust-lightning-bitcoinrpc if you need inspiration but not really not mandatory, be creative :p
06:02 -!- olinkl [b91cbb1a@185.28.187.26] has joined #rust-bitcoin
06:14 -!- rrybarczyk [sid364924@gateway/web/irccloud.com/x-curjcvtjncyrswpw] has joined #rust-bitcoin
06:17 -!- dr_orlovsky [uid398581@gateway/web/irccloud.com/x-inuqrwbnriwhncet] has joined #rust-bitcoin
06:26 -!- olinkl [b91cbb1a@185.28.187.26] has quit [Ping timeout: 260 seconds]
07:07 -!- olinkl [2578cc17@37.120.204.23] has joined #rust-bitcoin
07:43 -!- jonatack [~jon@185.28.187.26] has quit [Ping timeout: 245 seconds]
08:28 -!- olinkl [2578cc17@37.120.204.23] has quit [Ping timeout: 260 seconds]
10:33 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined #rust-bitcoin
10:55 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
10:58 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
12:29 -!- notmandatory [~notmandat@204.128.192.100] has joined #rust-bitcoin
12:30 < notmandatory> Hi I'm working on an Android app that needs an embedded bitcoin wallet and would like to try using the rust-wallet lib, has anyone tried creating JNI bindings for it? If not I'm going to take a stab at it
12:30 -!- notmandatory [~notmandat@204.128.192.100] has quit [Quit: Quit]
12:30 -!- notmandatory [~notmandat@204.128.192.100] has joined #rust-bitcoin
12:35 -!- notmandatory [~notmandat@204.128.192.100] has quit [Read error: Connection reset by peer]
12:56 -!- notmandatory [~notmandat@204.128.192.100] has joined #rust-bitcoin
13:51 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Quit: jonatack]
14:20 < BlueMatt> elichai2: hmm, whats the point of this
14:20 < BlueMatt> https://github.com/rust-bitcoin/rust-secp256k1/commit/811e8d24e954f780ec9405095fe4dfefd10453b7#diff-6334ae0f062c466145cf2dc022e0359a
14:20 < BlueMatt> and can we make it a feature
14:22 < elichai2> That we're doing the allocations inside of rust. Not in the C code, that way there's no need for malloc symbols
14:23 < BlueMatt> elichai2: ok, let me not commit the cardinal sin or asking for something isntead of describing my goal.....I'm linking rust-bitcoin/rust-secp256k1 into bitcoin core
14:23 < BlueMatt> rust-secp256k1 appears to use a newer secp with the allocate-in-place symbols, which are missing
14:24 < BlueMatt> but if I straight copy the deps folder into bitcoin core's secp256k1, I'm missing the create/destroy symbols
14:24 < BlueMatt> I assume at some point bitcoin core will grow the allocate-in-place symbols (are they upstream)?
14:24 < BlueMatt> so I can just hack around it for now
14:25 < elichai2> wait. you're compiling a rust + core program? (i.e. bitcoin-consensus)
14:26 < BlueMatt> no, I'm compiling bitcoin core itself, with a module that depends on rust-bitcoin (and, thus, rust-secp, but of course I dont want to double-link libsecp, so I'm linking rust-secp to the libsecp built in bitcoin core's build system)
14:26 < elichai2> because the symbols *are* available, just through rust instead: https://github.com/rust-bitcoin/rust-secp256k1/blob/master/src/ffi.rs#L269
14:26 < elichai2> as long as you depend on rust-secp with the std feature you will get the symbols
14:27 < elichai2> https://github.com/rust-bitcoin/rust-secp256k1/pull/130
14:27 < BlueMatt> no I'm not using the libsecp in rust-bitcoin/deps, I'm using the libsecp in bitcoin/src/secp
14:27 < BlueMatt> so I need to link rust-secp against *virgin* upstream libsecp
14:28 < elichai2> oh right. you should copy upstream. it has both the new stuff and the symbols aren't deleted
14:28 < BlueMatt> are the rust-secp std symbols going to conflict?
14:28 < BlueMatt> looks like the secp256k1_context_create symbol is going to, at lest?
14:29 < elichai2> 1. bitcoin-core has an old libsecp. 2. rust-secp has a new one but with the secp256k1_context_create implemented in rust with C symbols
14:29 < elichai2> yeah you can't use upstream + rust-secp
14:29 < BlueMatt> right, so 1 is solvable with an update, 2 I'd need to drop bits of rust-secp
14:29 < BlueMatt> yes, the question isn't "can I", its "what do I/we need to do to make it possible :p
14:30 < BlueMatt> cause the goal of this work isn't a toy, I want upstream this eventually.....
14:30 < elichai2> if you have rust-secp in the build system together with another libscp you'll have tons of symbols collisions, not just the create
14:30 < elichai2> (I might not be understanding you 100% as it is very late here lol)
14:31 < BlueMatt> I'm *not* building with cargo aka I'm not running the rust-secp build.rs
14:31 < BlueMatt> so not linking that at all
14:31 < elichai2> ohhhh
14:31 < elichai2> ok
14:31 < BlueMatt> so I otherwise dont get conflicts
14:31 < elichai2> gotcha.
14:32 < elichai2> so if you have an up to date secp, you'll need to strip `secp256k1_context_create + secp256k1_context_destroy` either from the rust side or the C side
14:33 < elichai2> but in linking it should resolve as long as these symbols are in one of them (the rust side and the C side will compile fine without, them. but if you have C code that calls these 2 symbols then you need them somewhere)
14:33 < BlueMatt> right, ok
14:33 < elichai2> the rust-secp side doesn't call these at all, they're just exposed for C uses
14:33 < BlueMatt> will try that and see where I get
14:33 < elichai2> (i.e. the bitcoin-consensus use case)
14:33 < elichai2> feel free to share code and if i'm still awake I can try to help heh
14:34 < BlueMatt> lol thats so dirty
14:34 < BlueMatt> nah, I should be able to figure that out
14:34 < BlueMatt> thanks
14:34 < BlueMatt> right, yea, only error now is duplicate context_create :)
14:34 < elichai2> yeah haha. it is a bit dirty, the whole rust-C ffi world is very dirty lol
14:35 < BlueMatt> right, this is incredibly groww
14:35 < BlueMatt> the fact that we're replacing C functions that are called by eg bitcoincosnensus with rust ones is.............really defeats the spirit of bitcoinconsensus lol
14:35 < elichai2> I wonder if there's some way to mangle symbols when statically link such that you can easily link to the same lib twice (and then let LTO do it's thing)
14:35 < elichai2> BlueMatt: it's just memory allocation
14:35 < BlueMatt> yay, it linked!
14:35 < elichai2> nothing more than that
14:35 < BlueMatt> I know, but even still
14:35 < elichai2> nice :)
14:36 < BlueMatt> nah, I'd rather not end up with two secps....just use the one thats there anyway
14:36 < elichai2> when we'll start using liballoc at least we could do this a bit better(or at least more explicit about sizes/alignments etc.)
14:37 < elichai2> without needing to manage our own little malloc lol
14:43 -!- notmandatory [~notmandat@204.128.192.100] has quit [Remote host closed the connection]
14:43 -!- notmandatory [~notmandat@204.128.192.100] has joined #rust-bitcoin
14:52 < BlueMatt> elichai2: whats the story with lax_der_parsing?
14:52 < BlueMatt> looks like rust-secp exposes it (for what?) but secp doesn't even build it by default?
14:53 < elichai2> Ophh that's the Bitcoin core parsing
14:53 < elichai2> Good old openssl
14:53 < BlueMatt> right, but we soft forked that out long ago
14:53 < BlueMatt> its not required anymore
14:53 < BlueMatt> and bitcoin core doesnt even build it afaict (or, I'm getting link errors)
14:55 < elichai2> what, bitcoin core should build it
14:55 < elichai2> look in CPubKey::Verify
14:55 < BlueMatt> static int ecdsa_signature_parse_der_lax(const secp256k1_context* ctx, secp256k1_ecdsa_signature* sig, const unsigned char *input, size_t inputlen) { is in src/pubkey.cpp
14:55 < BlueMatt> bitcoin core has its own copy, I guess?
14:55 < elichai2> oh so I guess it's a copy
14:55 < elichai2> ha
14:55 < elichai2> yeah
14:55 < BlueMatt> I guess I need to make that non-static....obnoxious that its that way
14:55 < BlueMatt> wtf
14:56 < elichai2> idk why it's copied to there
14:56 < elichai2> it's weir
14:56 < BlueMatt> I guess to make it static? I'll ask sipa
14:57 < elichai2> and what does static helps with? optimization? :/
14:58 < BlueMatt> in theory, yes
14:58 < BlueMatt> means can-be-inlined-right-away
14:58 < BlueMatt> but, still....
14:59 < BlueMatt> see core-dev
14:59 < BlueMatt> sipa says cause its Consensus, so awkward to have it as a dependency
15:00 < BlueMatt> <sipa> the code in secp256k1 is demo that could diverge from the consensus code used in bitcoin <-- I think that means we Really (tm) need to rip it out of libsecp and add it as our own explicitly
15:00 < BlueMatt> like, copy that function
15:00 < BlueMatt> in rust-secp
15:03 < elichai2> not sure I follow. you want to reimplement it in rust? do we even use that function in rust-secp? we might need to just disable the building of it there
15:04 < elichai2> oh yeah there's a `from_der_lax`
15:07 < BlueMatt> no, I mean we should remove it wholesale, unless we see a reason for it
15:07 < BlueMatt> is it needed to parse the chain?
15:07 < BlueMatt> we have soft-forked it out, but maybe some older sigs require it?
15:08 < BlueMatt> otherwise we should remove it? bitcoinconsensus already links it in directly via pubkey.cpp
15:11 < elichai2> Yeah if you want to verify an old signature using rust-secp you can use that function
15:12 < elichai2> I think it's kinda what I meant for sipa, that it seems like libsecp provides the consensus code while in practice it doesn't. The consensus code is in core pubkey.cpp
15:13 < BlueMatt> right, libsecp provides a signature verification algorithm, parsing garbage confusingly-encoded signatures in a consensus-compatible way into libsecp signatures is not a supported feature
15:13 < BlueMatt> which I totally get
15:13 < BlueMatt> but also probably means we should drop it from rust-secp
15:14 < BlueMatt> or rewrite it in rust (with a fuzz target that compares the rust and C++ versions)
15:18 < elichai2> It seems like Andrew server is offline? Andytoshi
15:19 < BlueMatt> yea
16:42 -!- willcl_ark [~quassel@95.211.225.220] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
17:21 -!- notmandatory [~notmandat@204.128.192.100] has quit [Ping timeout: 276 seconds]
17:34 -!- notmandatory [~notmandat@2607:fb90:56e1:7556:634c:4a23:48f0:4425] has joined #rust-bitcoin
17:37 -!- notmandatory [~notmandat@2607:fb90:56e1:7556:634c:4a23:48f0:4425] has quit [Remote host closed the connection]
17:37 -!- notmandatory [~notmandat@2607:fb90:56e1:7556:634c:4a23:48f0:4425] has joined #rust-bitcoin
17:42 -!- notmandatory [~notmandat@2607:fb90:56e1:7556:634c:4a23:48f0:4425] has quit [Ping timeout: 250 seconds]
17:42 -!- notmandatory [~notmandat@2607:fb90:56e0:f9b0:184e:5dec:6724:446] has joined #rust-bitcoin
17:46 -!- notmandatory [~notmandat@2607:fb90:56e0:f9b0:184e:5dec:6724:446] has quit [Ping timeout: 250 seconds]
17:47 -!- notmandatory [~notmandat@cpe-76-169-37-102.socal.res.rr.com] has joined #rust-bitcoin
20:10 -!- notmanda_ [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined #rust-bitcoin
20:10 -!- notmandatory [~notmandat@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: Quit]
20:10 -!- notmanda_ [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Client Quit]
20:11 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined #rust-bitcoin
23:10 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...]
--- Log closed Sat Oct 19 00:00:38 2019