--- Day changed Thu Mar 30 2017
02:05 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]     
06:04 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]     
06:05 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1     
06:41 < ofek> can anybody here using macOS try a thing for me?
06:41 < ofek> pip install coincurve  then  python -m timeit -s "from coincurve import PrivateKey" "PrivateKey().pubkey.serialize(compressed=True)"
07:39 < bsm117532> ofek: what's the point of forking ludbb's cffi bindings?
07:41 < bsm117532> Also you didn't fork it correctly on github, so I can't easily see what you changed...
07:44 < ofek> bsm117532, wanted new features: support for Windows now, support for Python 3.6, Linux, macOS, and Windows all have binary packages for both 64 and 32-bit, a fix to remove CFFI warnings, Linux & macOS wheels now use GMP, endomorphism optimization is now enabled
08:11 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]     
08:13 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1     
09:31 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #secp256k1     
10:51 < ofek> would a user actually ever use their own context? I want to remove that logic from my Python bindings and always use a global context
10:56 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-huuxzndpbbfuorbq] has joined #secp256k1     
10:59 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 276 seconds]     
10:59 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-cmowtusapalzaldh] has quit [Ping timeout: 276 seconds]     
10:59 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #secp256k1     
11:09 < gmaxwell> ofek: a global context is not concurrency safe (not for setup and not for rerandomization)
11:12 < ofek> gmaxwell, so, say I'm running a service where each request gets its own process. that means I need to create a new context for every user's request?
11:12 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host]     
11:12 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #secp256k1     
11:13 < sipa> ofek: sigh, no
11:13 < sipa> you need exclusive access for destruction and randomization
11:13 < sipa> otherwise multiple threads can access the context simuktaneously
11:14 < gmaxwell> gets its own _process_ ?  if the processes share nothing, then they share nothing.
11:14 < sipa> and i guess yiu mean thread, not process. a process likely has no shared memory at all
11:27 < ofek> sipa, so for multi-threaded uses I need to put a lock around each key creation basically?
11:29 < sipa> ofek: wtf?
11:29 < sipa> 18:13:33 < sipa> you need exclusive access for destruction and randomization
11:29 < sipa> i didn't say anything about key creation
11:30 < ofek> sipa, I thought randomization == key creation :(
11:30 < sipa>  *  Do not create a new context object for each operation, as construction is
11:30 < sipa>  *  far slower than all other API calls (~100 times slower than an ECDSA
11:30 < sipa>  *  verification).
11:30 < sipa>  *     
11:30 < sipa>  *  A constructed context can safely be used from multiple threads
11:30 < sipa>  *  simultaneously, but API call that take a non-const pointer to a context
11:30 < sipa>  *  need exclusive access to it. In particular this is the case for
11:30 < sipa>  *  secp256k1_context_destroy and secp256k1_context_randomize.
11:30 < sipa>  *     
11:30 < sipa>  *  Regarding randomization, either do it once at creation time (in which case
11:30 < sipa>  *  you do not need any locking for the other calls), or use a read-write lock.
11:30 < sipa> ^ from secp256k1.h
11:31 < sipa> (sorry for the big paste)
11:31 < sipa> if you never randomize after creation, you don't need a lock
11:31 < sipa> creation _of the context_ to be clear
11:43 -!- bsm117532 [~mcelrath@135.84.167.210] has quit [Remote host closed the connection]     
11:46 < ofek> sipa, gmaxwell, last question please.. how would you go about sharing a context between processes? is there a way to create a context from all of the precomputed values and I could just store it in like LMDB?
11:50 < nsh> you'll need to use shmem or some other IPC
11:50 < nsh> don't know if there exists received practice for this or not
11:50 < sipa> ofek: don't
12:01 < gmaxwell> if you're creating a _process_ per connection your performance will be trash regardless of how many contexts you create. creating a context is slow, but probably not slow compared to starting a process.
12:14 < ofek> do you always need to call secp256k1_context_randomize after secp256k1_context_create?
12:16 < sipa> only if you want to protect against certain sidechannel attacks
12:16 < sipa> read the .h file
12:17 < instagibbs> https://github.com/bitcoin-core/secp256k1/commit/70ff29b6a77266c55f41c966cfc2a766fd252cdf
12:17 < instagibbs> fairly recent documentation
12:18 < ofek> ah ty both
13:09 -!- echonaut [~echonaut@46.101.192.134] has quit [Ping timeout: 240 seconds]     
13:21 -!- echonaut [~echonaut@46.101.192.134] has joined #secp256k1     
19:10 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
19:12 < ofek> https://github.com/ofek/coincurve/blob/master/coincurve/__init__.py#L43
19:13 < ofek> any reason why lubdd used 74?
19:13 < ofek> I think it should be 72
19:13 < ofek> https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#DER_encoding
19:14 < ofek> 'the total signature size being at most 72 bytes'
19:14 < sipa> 72 is the correct number, but not for the reason you say
19:15 < sipa> Bitcoin adds a sighash type byte at the end, so the output from libsecp256k1 is in fact at most 71 bytes
19:15 < sipa> ah, no, 71 would be enough even, i think
19:16 < ofek> sipa, oh ok ty. any idea why 74 was chosen?
19:16 < sipa> no clue
19:16 < ofek> ok :)
19:17 < sipa> if you have signatures without low-s, it may be 72