--- Day changed Tue Oct 30 2018 11:42 < stevenroose> andytoshi: https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/address.rs#L200 11:42 < stevenroose> Exactly when would that go away? 12:21 < andytoshi> stevenroose: heh, probably when bitcoin-constants becomes a crate 12:28 < stevenroose> andytoshi: could you explain briefly why exactly the Secp256k1 context object is required? It confuses me a bit and it makes some interfaces quite awkward. Like needing a Secp256k1 context to convert a bitcoin::PublicKey into a bitcoin::Address.. 12:34 < andytoshi> because upstream requires it 12:34 < andytoshi> most context objects contain precomp tables, which some operations (signing and verifying signatures) require 12:35 < stevenroose> hmm 12:35 < stevenroose> and how about the without_caps one? 12:36 < andytoshi> upstream requires it to make the API consistent and more future-proof. it doesn't do anything currently. 12:37 < stevenroose> hmm, k makes sense :) do users usually use a single context for all their operations? 12:38 < andytoshi> yes 12:41 < andytoshi> in elements there are a couple global variables that hold variously-capable contexts 12:41 < andytoshi> but rust really discourages this kind of programming 17:13 < stevenroose> andytoshi: yeah just the way to declare globals with the 'static lifetime thing is evidence of that 17:31 < andytoshi> rust-secp 0.12 will get rid of the capability-less contexts 17:32 < andytoshi> we don't care about "API forward-compatibility" is much, given that we have a decent dependency management system, unlike C 19:56 < stevenroose> oh so serializing etc will be context-less? that's nice :) 19:56 < stevenroose> tbh I've been just creating a without_caps whenever I needed serialization 19:56 < stevenroose> :| 20:08 < andytoshi> yeah, that's the easiest thing to do for now 20:08 < andytoshi> but it's pretty crappy, every time you do that you call malloc() for like 20 bytes