--- Log opened Wed Feb 02 00:00:48 2022
00:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
00:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 252 seconds]
01:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
01:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 260 seconds]
01:49 -!- peter35 [~peter@197.210.8.97] has joined #bitcoin-core-pr-reviews
01:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
01:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 245 seconds]
02:00 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has joined #bitcoin-core-pr-reviews
02:03 -!- |avril [av@user/avril] has joined #bitcoin-core-pr-reviews
02:04 -!- avril [av@user/avril] has quit [Ping timeout: 268 seconds]
02:04 -!- |avril is now known as avril
02:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
02:50 -!- peter35 [~peter@197.210.8.97] has quit [Ping timeout: 250 seconds]
02:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 252 seconds]
03:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
03:49 -!- peter29 [~peter@197.210.8.97] has joined #bitcoin-core-pr-reviews
04:32 -!- peter29 [~peter@197.210.8.97] has quit [Ping timeout: 252 seconds]
05:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Remote host closed the connection]
05:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
05:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Remote host closed the connection]
05:24 -!- dunxen [~dunxen@gateway/tor-sasl/dunxen] has joined #bitcoin-core-pr-reviews
05:28 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
06:25 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection]
06:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
06:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 250 seconds]
06:57 -!- in3rsha [~in3rsha@185.204.1.209] has joined #bitcoin-core-pr-reviews
07:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
07:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 252 seconds]
07:35 < michaelfolkson> Some history on the secp256k1 library is here for those that are interested :) https://btctranscripts.com/chaincode-labs/chaincode-podcast/2020-01-28-pieter-wuille/#part-2
07:35 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has joined #bitcoin-core-pr-reviews
07:35 -!- Murch [~murch@user/murch] has joined #bitcoin-core-pr-reviews
07:35 -!- siv2r[m] [~siv2rmatr@2001:470:69fc:105::fed3] has joined #bitcoin-core-pr-reviews
07:35 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #bitcoin-core-pr-reviews
07:35 -!- jomat [~jomat@2001:470:69fc:105::21] has joined #bitcoin-core-pr-reviews
07:35 -!- willcl_ark [~willcl-ar@user/willcl-ark/x-8282106] has joined #bitcoin-core-pr-reviews
07:35 -!- sipa [~sipa@user/sipa] has joined #bitcoin-core-pr-reviews
07:35 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #bitcoin-core-pr-reviews
07:35 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #bitcoin-core-pr-reviews
07:38 -!- dome [~textual@50-250-87-150-static.hfc.comcastbusiness.net] has joined #bitcoin-core-pr-reviews
07:43 -!- inersha [~in3rsha@185.204.1.225] has joined #bitcoin-core-pr-reviews
07:46 -!- in3rsha [~in3rsha@185.204.1.209] has quit [Ping timeout: 256 seconds]
07:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
07:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 250 seconds]
07:57 < michaelfolkson> Can I ask a basic API question? What's the difference between calling into internal functions (discouraged) and safe usage of the API? Is it just a question of which internal functions you can safely call and which you can't?
07:58 < sipa> By whom?
07:58 < sipa> Internal functions you just cannot call from the outside.
07:58 < dome> In general? Usually internal APIs are subject to change, but official APIs will respect semver
07:59 < dome> Not related to bitcoin, just a general rule of thumb w/ software is how I view that
08:00 < michaelfolkson> I guess with proprietary permissioned APIs you are granted permission to request certain data from a third party server. I'm not sure what an open source library API is exactly. You can use it however you like (though ideally you'd use it safely)
08:02 < dome> Yeah I mean you can RE a bunch of different APIs that are being used by proprietary apps, a lot of people use them to get whatever functionality they want, but they're not guaranteed to be backward compatible or not break at any given moment. That's the real "danger" with using them in another app
08:03 < michaelfolkson> When you build Core you build secp256k1 with it so presumably Core can use any internal functions of secp256k1
08:04 < michaelfolkson> And if something else other than Core (say a hardware wallet library) built secp256k1 with it then surely it can also use any internal functions of secp256k1
08:05 < michaelfolkson> [15:58:12]  <sipa> Internal functions you just cannot call from the outside.
08:06 < michaelfolkson> This suggests there are functions that can be called and internal functions that say can't be called by Core, hardware wallet library. Is that right?
08:06 -!- rukundo [~rukundo@h1b6a.n1.ips.mtn.co.ug] has joined #bitcoin-core-pr-reviews
08:07 -!- sha [~sha@cpe-98-14-66-91.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews
08:07 -!- sha is now known as Guest3637
08:15 < glozow> can you clarify what you mean by an internal function? a function that isn't exposed in the header file is not visible to when including the library.
08:16 < michaelfolkson> So for example secp256k1 needs to access hash functions in Core to create signatures. So secp256k1 asks Core for the hash and Core returns it. Are there restrictions on what secp256k1 can ask from Core and vice versa? Is that what we mean by the API?
08:16 < glozow> not visible to a prospective caller*
08:16 < michaelfolkson> glozow: But you could easily add to the header file right? That would just be discouraged?
08:17 < glozow> i don't think secp256k1 needs to access hash functions in Core, the hash of the message should be passed in as an argument to the signing function
08:18 < michaelfolkson> So the API is what has been defined in header file and it is recommended by the libsecp authors that this isn't added to?
08:18 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
08:19 < michaelfolkson> glozow: Right, agreed on passing argument to signing function. I wasn't being precise enough.
08:21 < glozow> so in this hypothetical scenario, a user is modifying the library for their own usage?
08:22 < robot-dreams> michaelfolkson: Can you name a specific "internal function" of secp256k1 that you imagine a client calling in a "discouraged" way?
08:22 < michaelfolkson> Right, that would be discouraged? Effectively tinkering with the API and not following a safe usage example that we'll cover later?
08:23 < lightlike> michaelfolkson: you can technically, but then you have created your own fork of the library, and have to live with the consequences (upgrading will be a pain because no one upstream will care about keeping the interface of internal functions stable). 
08:23 < glozow> the usage examples are, AFAIK, for someone including the library as is.
08:23 < sipa> michaelfolkson: libraries are exported symbols; external users can only access those
08:23 -!- kalpa [~kalpa@ip-005-146-160-032.um05.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews
08:24 < sipa> if you use a modified version of the library, you can of course export more things
08:24 < sipa> is that discouraged... i don't know, it's open source you can do what you want
08:24 < robot-dreams> michaelfolkson: the reason I ask is because, I wonder if the "internal functions" you're worried about are static and it's literally not possible to be called by a client (assuming the client includes the "secp256k1.h" and links the secp256k1 object file in their build)
08:25 < sipa> the libraries' authors and maintainers have a vision of how users should be using the library of course, and perhaps if you want to deviate from that you should have reasons to
08:25 < sipa> we could also be idiots, of course
08:26 < sipa> or maybe you need a different library, with a different use case
08:27 < michaelfolkson> robot-dreams: Not worried about using the library/API as is, just wondering how much flexibility you have to say make one change to a header file. Or whether that is venturing into "rolling your own crypto" territory
08:27 < sipa> just adding a header file doesn't do anything
08:28 < sipa> it'll fail at linking time if you add a function to the header without also modifying the library to provide and export such a function
08:28 < michaelfolkson> Right, but then using that function exposed in the header file for something *handwave*
08:29 < sipa> yes, that'll fail at linking time
08:29 < michaelfolkson> Ok, thanks
08:29 < sipa> the header tells callers how they can call exported library functions
08:29 < sipa> but if the header and the exported library functions mismatch you'll still get an error
08:29 < sipa> you also need to modify the library actually export those new functions
08:30 -!- rukundo [~rukundo@h1b6a.n1.ips.mtn.co.ug] has quit [Quit: Connection closed]
08:30 < sipa> and regarding SHA256... libsecp256k1 does have its own SHA256 implementation actually
08:30 < robot-dreams> "I modified the header, then I modified the rest of the library so the result would compile", I think that voids your warranty
08:31 < sipa> for ECDSA, the caller provides the message hash to libsecp256k1, and it can sign/verify/whatever
08:31 < michaelfolkson> Know next to nothing about the build system. Luckily there is a review club on that in a few weeks :)
08:31 < sipa> for BIP340, you provide the message itself, and libsecp256k1 does the hashing
08:32 < robot-dreams> By the way, sipa is it correct that the reason this usage example PR doesn't use the internal SHA256 implementation is that it's internal, thus unexported, thus inaccessible from the example
08:32 < sipa> well, (a) because it can't and (b) because it shouldn't
08:33 < sipa> libsecp256k1 isn't a generic crypto library that does SHA256... it has a very simple unoptimized implementation for it so it can do RFC6979 etc
08:33 < sipa> i think we've had some talks about reversing it... allowing callers to provide their own SHA256 implementation to the library
08:34 < sipa> We could add a new API function that takes an unhashed message, and does the hashing for you... but in what way? e.g. Bitcoin uses double-SHA256 to obtain the message hash.
08:35 < sipa> So any way of doing that would either not match Bitcoin's usage of ECDSA, or still require the caller to do one of the two hashing steps.
08:35 < sipa> , or not be standard
08:40 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection]
08:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
08:54 -!- OliverOffing [~OliverOff@189.1.174.52] has joined #bitcoin-core-pr-reviews
08:54 -!- Clint65 [~Clint@68-255-237-145.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-core-pr-reviews
08:54 < Kaizen_Kintsugi_> Noob question here, what is the point of double sha256?
08:54 -!- jules23 [~jules23@dyn-160-39-193-156.dyn.columbia.edu] has joined #bitcoin-core-pr-reviews
08:55 < sipa> I'm afraid you'll need to ask Satoshi.
08:55 -!- elichai2 [sid212594@id-212594.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
08:56 -!- Jello64 [~Jello@IGLD-84-229-44-23.inter.net.il] has joined #bitcoin-core-pr-reviews
08:56 < robot-dreams> See https://bitcoin.stackexchange.com/a/110142/109853 for more context 
08:56 -!- bitcoin1o1 [~bitcoin1o@189.132.107.48] has joined #bitcoin-core-pr-reviews
08:56 -!- jimmysong [~jimmysong@72-48-253-168.dyn.grandenetworks.net] has joined #bitcoin-core-pr-reviews
08:57 -!- sanya [~sanya@79-101-150-15.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
08:57 -!- Azor [~Azor@190.79.223.248] has joined #bitcoin-core-pr-reviews
08:57 < Kaizen_Kintsugi_> oh I see
08:57 < Kaizen_Kintsugi_> It is legacy
08:57 -!- real_or_random [~real_or_r@user/real-or-random/x-4440763] has joined #bitcoin-core-pr-reviews
08:58 < Kaizen_Kintsugi_> robot-dreams: this is an excellent overview thanks, I take it this double hashing is so embedded it is impossible to pull out?
08:58 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
08:59 -!- effexzi [uid474242@ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
08:59 < robot-dreams> Note that the excellent overview is written by sipa :) and yeah I'd guess there's no hope of changing the double hashing
08:59 -!- jesseposner_ [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
09:00 < Kaizen_Kintsugi_> AH I see, as you guys upgrade the process on things like P2WSH taproot ect, you dont have to do that anymore
09:00 < glozow> #startmeeting
09:00 < stickies-v> hi!
09:00 < Kaizen_Kintsugi_> Learning time!
09:00 < jimmysong> hi
09:00 < nickler> hello hello
09:00 < bitcoin1o1> hi
09:00 < robot-dreams> hello
09:00 < Kaizen_Kintsugi_> I am excited for this one!
09:00 < jesseposner_> hi
09:00 < theStack_> hi
09:00 < MarcoFalke> hi
09:00 < michaelfolkson> hi
09:00 < elichai2> Hi
09:00 < real_or_random> hi
09:00 < effexzi> Hi
09:00 < svav> Hi All
09:00 < kalpa> hi
09:00 -!- Guest3637 is now known as Sha256
09:00 -!- Praveen [~Praveen@192.157.127.6] has joined #bitcoin-core-pr-reviews
09:00 -!- engraving [~engraving@195.181.160.173.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
09:00  * engraving waves
09:00 < glozow> Hello welcome to a special edition of PR review club! we're looking at a libsecp PR today https://bitcoincore.reviews/libsecp256k1-748
09:01 -!- Sha256 is now known as mninja
09:01 < OliverOffing> hi!
09:01 < michaelfolkson> Lots of Jonas Brothers fans here I see
09:01 < Kaizen_Kintsugi_> lots of people here today
09:01 < brunoerg> hi
09:01 < ziggie> hi
09:01 < emzy> hi
09:01 < siv2r[m]> hi
09:01 < Clint65> howdy
09:01 < Kaizen_Kintsugi_> damn
09:01 < mninja> hi all, first time, happy to be here :)
09:01 < glozow> shoutout to real_or_random, elichai2, nickler, jesseposner_, robot-dreams, thanks for being here
09:01 < lightlike> hi
09:01 < glozow> and thanks nickler for being our host today, passing it onto you :)
09:01 < sipa> hi
09:02 < willcl_ark> hi
09:02 < glozow> oh and sipa, sorry!
09:02 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:02 < jnewbery> hi
09:02 < nickler> Ok, I volunteered to be the host this session, but this is my first time doing this so please let me know if this session is not going in the right direction.
09:02 < nickler> I was also reminded to mention that you don’t need to wait for the host to ask a specific question — you can just jump in at any point
09:02 < nickler> Q1: did everyone get a chance to have a look at the PR? How about a quick y/n from everyone
09:02 < MarcoFalke> n
09:02 < jimmysong> y
09:02 < glozow> y
09:02 < stickies-v> y
09:02 < effexzi> N
09:02 < emzy> y (tested)
09:02 < Praveen> N
09:02 < theStack_> y
09:02 < Kaizen_Kintsugi_> y
09:02 < michaelfolkson> y
09:02 < jnewbery> y
09:03 < robot-dreams> y
09:03 < jesseposner_> y
09:03 < bitcoin1o1> y (tested on Mac)
09:03 < larryruane> hi
09:03 < svav> yes i read the notes
09:03 < Clint65> n
09:03 < nickler> That's quite a lot of people , thanks everyone for showing interest in libsecp dev
09:04 < nickler> Perhaps you've noticed that we split the questions into two: 1) questions that are directly relevant to reviewing the PR 2) "further" questions that may help exploration of libsecp concepts We'll start with the first set of questions. Let's see how far we come.
09:04 < svav> How long has libsecp been in existence?
09:04 < siv2r[m]> y
09:04 < nickler> Question 1: Can you compile and run the example? Any troubles
09:04 < sipa> Started as a hobby project of mine in 2013.
09:05 < glozow> y, no troubles
09:05 -!- rishabh [~rishabh@14.139.82.6] has joined #bitcoin-core-pr-reviews
09:05 < robot-dreams> y, compiles and runs fine
09:05 < jesseposner_> I was able to compile and run all the examples. At least once I read the docs and figured out all the configure flags I had to set. :-)
09:06 < larryruane> I was able to build the `ecdsa_example` binary, but should there be other example binaries (ecdh, schnorr)?
09:06 < nickler> Also important to check, does the printed output make sense? Correct exit code? etc
09:06 < glozow> ./configure --enable-examples --enable-module-ecdh --enable-experimental --enable-module-schnorrsig for anyone wanting to do it rn
09:06 < emzy> y, no troubles, worked.
09:06 < theStack_> y, examples compiled and ran fine on OpenBSD 7.0... after setting the right configure flags :)
09:06 < stickies-v> y, ran smoothly - although I was slightly surprised the builds were in root and not in ./examples/,
09:06 < elichai2> theStack_: Good to hear they work properly on OpenBSD :)
09:06 -!- tarun [tarun@gateway/vpn/protonvpn/tarun] has joined #bitcoin-core-pr-reviews
09:06 < b10c> hi
09:07 < jesseposner_> larryruane: the other examples require additional flags to be set (i.e. experimental, ecdh, echnorrsig)
09:07 < glozow> larryruane: there should be schnorr_example and ecdh_example in root
09:07 -!- javed [~javed@103.176.140.6] has joined #bitcoin-core-pr-reviews
09:07 < nickler> larryruane: there's a suggested update to the README in the PR that would make it more clear that the modules need to be enabled
09:07 < larryruane> also I ran `./configure CFLAGS='-O0 -g' --enable-examples ...` so I could explore with the debugger
09:07 < michaelfolkson> elichai2: You want someone on Windows right? :)
09:08 < larryruane> glozow: thanks, now I have them
09:08 < jnewbery> stickies-v: I was also surprised that they binaries were built in the root directory
09:08 < glozow> i was also able to use gdb with the examples without modifying flags
09:08 < nickler> jnewbery: stickies-v: good point. not great if the root dir gets DOS'd
09:09 -!- skme [~skme@94.140.8.169] has joined #bitcoin-core-pr-reviews
09:09 < siv2r[m]> glozow: libsecp by default set the `-g` flag during the build
09:09 < nickler> But ok, seems like no major troubles, good!
09:09 < emzy> If i'm right "make check" also runs the examples.
09:10 < nickler> correct, it should emzy
09:10 < robot-dreams> glozow: I was able to debug as well, but I did get `ecdh_example was compiled with optimization - stepping may behave oddly; variables may not be available.` so I think larryruane's `CLAGS='-O0'` is still helpful
09:10 < bitcoin1o1> y, on mac, no problem
09:10 < larryruane> I love how fast everything builds (relative to bitcoin core)!
09:10 -!- Jello64 [~Jello@IGLD-84-229-44-23.inter.net.il] has quit [Ping timeout: 256 seconds]
09:10 < theStack_> larryruane: heh, i thought the same w.r.t. compilation speed
09:10 < glozow> robot-dreams: ah thanks
09:10 < emzy> yes I got a "PASS: schnorr_example ....." from make check
09:11 < real_or_random> robot-dreams: but then you need CFLAGS='-O0 -g'. We only have -g in our *default* CFLAGS but if the user sets CFLAGS they have the last word
09:11 < nickler> glozow: when should the host move to the next question? :D
09:11 -!- alex_waltz [~alex_walt@217.146.82.84] has joined #bitcoin-core-pr-reviews
09:11 < glozow> nickler: whenever they want
09:11 < glozow> now's probably good
09:11 < nickler> 3. Question 1: Can you compile and run the example? Any troubles
09:11 < nickler> wait
09:12 < nickler> 3. Why do the examples demonstrate how to obtain randomness? Is this a good idea?
09:12 -!- Jello54 [~Jello@IGLD-84-229-44-23.inter.net.il] has joined #bitcoin-core-pr-reviews
09:13 < nickler> You may have seen that the examples also show how to obtain randomness from OS.
09:13 < nickler> But instead we could just expect a random byte string to come from *somewhere*
09:13 < larryruane> Doesn't the library enable the user to provide the randomness? (Not built into the library) ... hence it's good to show the user the best ways to do it
09:13 < michaelfolkson> Assuming the demonstration is solid yes it is a good idea. Otherwise users may obtain imperfect sources of randomness
09:13 < svav> Is it because generating true randomness is rather difficult?
09:14 < stickies-v> if e.g. nonce generation is not truly random, it can be trivial for an attacker to derive your private key. A lot of RNGs are not truly random, because of bad implementation or because of different requirements (e.g. speed > security)
09:14 < nickler> I don't think it's answered in the PR history, but often the problem with crypto implementation _is_ obtaining randomness
09:14 < glozow> security of these schemes relies on the assumption that keys, nonces, salts, etc. are secret and/or uniformly distributed, so it makes sense to call attention to it
09:14 < jimmysong> Q: Is it normal to get this warning when I configure? "configure: WARNING: unrecognized options: --enable-examples"
09:14 < theStack_> definitely a good idea, as without proper randomness there are some attacks possible
09:14 < nickler> So without that, the examples would be much less helpful
09:15 < larryruane> jimmysong: i did not get that warning
09:15 -!- random_man [~random_ma@14.139.38.125] has joined #bitcoin-core-pr-reviews
09:15 < nickler> stickies-v: often it comes down to finding the right RNG (for your OS)
09:15 < jnewbery> jimmysong: perhaps you need to run autogen.sh again?
09:15 < jimmysong> ok, let me try that
09:15 < larryruane> i ran `./configure CFLAGS='-O0 -g' SECP_CFLAGS='-O0 -g' --enable-examples --enable-module-ecdh --enable-experimental --enable-module-schnorrsig`
09:15 < jesseposner_> it's critical to get good randomness, and it's not obvious how to do it properly, and it is platform dependent
09:15 < emzy> jimmysong: also had no warning.
09:15 < engraving>  nice phrasing glozow +1
09:15 < siv2r[m]> a good PRNG is required to avoid cryptographic attack ig. Ex: if schnorrsig use a LCG random generator we can derive the private key since, the nonces will be linearly related
09:16 < real_or_random> an interesting question is: how large is the burden of maintaining  these methods? OSes change
09:16 < jimmysong> jnewbery: that was it. warning is now gone
09:17 < nickler> real_or_random: yes! that's the "Is this a good idea?" part of above question
09:17 -!- rishabh [~rishabh@14.139.82.6] has quit [Ping timeout: 256 seconds]
09:17 < svav> In ecdh.c what does "Randomizing the context is recommended to protect against side-channel leakage" mean?
09:17 -!- jesseposner_ [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:17 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews
09:17 < glozow> The recommendation can become outdated if a vulnerability is found, the library is no longer maintained, etc. so it's nice that there's a warning message there
09:17 < michaelfolkson> real_or_random: How often do the sources of randomness change though? Surely extremely infrequently
09:17 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-pr-reviews
09:17 < nickler> svav: that's not specific to ecdh but also in the other files. you can read more about it in include/secp256k1.h
09:18 < jnewbery> perhaps that comment at the top of the file should actually be split up and put inline inside the fill_random() function, so if the OSs change or another is added, there's only one place that needs to be changed
09:18 < real_or_random> michaelfolkson: yeah, it's hopefully much better now... it took quite some time in linux for example to provide a good API 
09:18 < nickler> this ^
09:18 < michaelfolkson> I guess it depends what they use. if trivial changes to the OS could impact how the randomness is generated
09:19 < michaelfolkson> But that sounds like a flaw of the OS
09:19 < real_or_random> ok yes, but that will be a stupid change on the OS side
09:19 < jimmysong> so question about the context randomization, how come it's a separate call instead of it being done for you as part of the context creation?
09:19 < nickler> michaelfolkson: the problem is also that the OS' manpages are sometimes very confusing
09:19 < real_or_random> jimmysong: that's a good question. there's some discussion in https://github.com/bitcoin-core/secp256k1/issues/780
09:20 < theStack_> jimmysong: i guess partly because the library doesn't know what a good entropy source is?
09:20 < elichai2> michaelfolkson: and that some functions that are now OK are not ok in old versions of the OS (e.g. `arc4random`)
09:20 < real_or_random> (where I argue we should have a creation function that takes randomness as input)
09:20 -!- docallag [~docallag@2a02:8084:90e2:3a80:1cf0:5fbd:eef0:c61c] has joined #bitcoin-core-pr-reviews
09:20 < lightlike> doesn't bitcoin core have some more elaborate algorithm for gathering entropy/randomess than just using the OS syscall, combining randomness from multiple sources?
09:21 < sipa> yes
09:21 < real_or_random> lightlike: yes, it has. that's the reason why secp256k1 does not have a randomness generation function
09:21 < michaelfolkson> elichai2: So secp requires newer versions of those particular OSes?
09:21 < michaelfolkson> Warnings?
09:21 < nickler> Q4 and Q5 are very relevant for reviewing the PR.
09:21 < nickler> What are the recommendations for obtaining randomness on the supported operating systems? Do the examples correctly follow these recommendations?
09:22 < real_or_random> it's a litte strange: for bitcoin core as the main user of secp26k1, it does not matter. core has its functions and they work. the examples are intended for other users
09:22 < real_or_random> (the strange part is that this is a crypto library which is "bring your own randomness" and this is the part where a lot of people screw up)
09:23 < jesseposner> but if core has a superior method, should that method be documented so other users of the library can follow a similar pattern?
09:23 < elichai2> michaelfolkson: Notice that secp currently doesn't generate randomness anywhere, it expects the user to provide random strings. This is just in the examples. (but it could be argued that libsecp should maintain a "getrandom" function)
09:23 < larryruane> I think it's good that the library doesn't generate randomness (internally)
09:23 < jimmysong> real_or_random: so trying to clear up something from the discussion. Are we supposed to call the context_randomize function before each new signing?
09:23 < stickies-v> It looks like fill_random only partially follows recommendations, in that it doesn't implement the suggested fallbacks? 
09:24 < real_or_random> jimmysong: yes, it will make signing more secure by adding side-channel protection. (though that does not mean that signing is insecure if you don't do it)
09:24 < engraving> Why should the Core repo house the randomness algos?  Is that the ideal location?
09:24 < theStack_> as for obtaining randomness on OpenBSD, i think arc4random(3) should be preferred over getentropy(2), at least that's what the man pages suggest (see also https://github.com/bitcoin/bitcoin/pull/24238)
09:25 < glozow> Q4 relevant code is here i think https://github.com/bitcoin-core/secp256k1/blob/4c433823a85cac975b0746203d94ce041c10299d/examples/random.h#L37-L64 the examples use the `fill_random` function which is defined using preprocessor directives, depending on the operating system
09:25 < larryruane> stickies-v: well the fallbacks are determined at code-writing time (not at runtime), right?
09:25 < jimmysong> real_or_random: okay, that's good to know. I'll be adding that...
09:25 < sipa> jimmysong: Roughly, more blinding is better. How much is very hard to quantify.
09:25 < nickler> stickies-v: what do you mean exactly?
09:25 < sipa> Note that randomization is only needed for side-channel resistance.
09:26 < real_or_random> jesseposner: I think the Core method collects entropy from a lot of sources and is pretty sophisticated
09:26 -!- JDuse [~JDuse@81.29.24.126] has joined #bitcoin-core-pr-reviews
09:26 < nickler> theStack_: did you see this comment? https://github.com/bitcoin-core/secp256k1/pull/748/files#r603295709
09:26 < real_or_random> jesseposner: maybe it's a good idea to refer to it at least, not sure
09:27 < jesseposner> real_or_random: makes sense. I'm not familiar with the Core method so not sure how practical it is for other users to implement.
09:27 < jimmysong> sipa: got it. you can never be too paranoid.
09:27 < stickies-v> larryruane nickler the inline documentation in fill_random states that "/* If `getrandom(2)` is not available you should fallback to /dev/urandom */", but then it doesn't actually fallback?
09:27 < robot-dreams> stickies-v: Are you suggesting that `fill_random` should also try to read from `/dev/urandom` (or whatever the OS-specific fallback is)?
09:27 < elichai2> stickies-v: you're right.  `random.h` only contains "best practice" random generation. it doesn't contain any fallbacks for older machines, as that will require a lot more effort
09:28 < stickies-v> I'm not suggesting anything - that's just how I interpreted the documentation
09:28 < larryruane> stickies-v: hmm, well you can't determine if `getrandom(2)` is available at runtime, right? that's compile-time
09:28 < sipa> Yeah, it'd need #ifdef's etc.
09:28 < sipa> Or configure mechanisms to determine what exists etc.
09:29 < siv2r[m]> Is there any specific reason why getrandom() is used for Linux whereas getentropy() is used for macOS? availability issues?
09:29 < siv2r[m]> The GNU C library manual says this:
09:29 < siv2r[m]> Most applications should use getentropy. The getrandom function is intended for low-level applications which need additional control over blocking behavior.
09:29 < siv2r[m]> https://www.gnu.org/software/libc/manual/html_node/Unpredictable-Bytes.html
09:29 -!- Praveen [~Praveen@192.157.127.6] has quit [Quit: Connection closed]
09:29 < larryruane> here's a good article on side-channel attacks https://www.rambus.com/blogs/side-channel-attacks/
09:29 < sipa> Here is Bitcoin Core's code for getting randomness from the OS: https://github.com/bitcoin/bitcoin/blob/master/src/random.cpp#L276L349
09:29 < dhruv> jesseposner: Here's an example of core harvesting entropy from an inbound p2p message https://github.com/bitcoin/bitcoin/blob/196b4599201dbce3e0317e9b98753fa6a244b82d/src/net.cpp#L759
09:30 < elichai2> stickies-v: At the top of `random.h` it states that the file only contains best practices. But it's probably not clear enough, so please comment a suggestion :)
09:30 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
09:30 < jesseposner> dhruv: Thanks!
09:30 < real_or_random> one issue with these man pages is that sometimes they're wrong, too. for example the linux manpage was suggesting /dev/random over /dev/urandom for a while (fixed now)
09:31 < sipa> siv2r: That's certainly good to know. I don't think I was aware getentropy even existed in linux/glibc
09:31 < michaelfolkson> ccccccvkvigvgnibjgfgclrnklbuigknldjtjvvdehin
09:31 < nickler> bless you
09:31 < sipa> Are you ok, michaelfolkson?
09:31 < michaelfolkson> Oops sorry unintended entropy
09:32 < robot-dreams> He is just demonstrating the proper way to generate entropy
09:32 < kalpa> lol
09:32 < jaonoctus> oof
09:32 < nickler> Time to move to the actual examples?
09:32 < nickler> 6. Can you follow the examples? Is it clear how they should be generalized to a production system?
09:32 < sipa> https://dilbert.com/strip/2001-10-25
09:32 < jesseposner> dhruv: That's a good example of entropy sources that wouldn't necessarily be applicable to other applications (the time and checksum of a p2p message).
09:32 < emzy> sipa: a clasic.
09:32 < larryruane> I do remember quite a while ago, moving the mouse around to generate entropy .... I'm glad that's been improved upon!
09:33 < engraving> TrueCrypt did that I believe
09:33 < dhruv> jesseposner: yeah. makes it hard to generalize/document for other library users.
09:33 < glozow> for this question it was really fun to look at src/key.cpp and src/pubkey.cpp and compare with the usage in bitcoin core
09:33 < glozow> e.g. `CKey::SignSchnorr` https://github.com/bitcoin/bitcoin/blob/219d728fcbde8c313940788838afa46c2fb88762/src/key.cpp#L278
09:33 < glozow> and `CKey::Sign` https://github.com/bitcoin/bitcoin/blob/219d728fcbde8c313940788838afa46c2fb88762/src/key.cpp#L213
09:33 < jimmysong> larryruane: https://www.bitaddress.org still does that
09:33 < michaelfolkson> larryruane: Bitaddress too for generating seed
09:34 < stickies-v> nickler yeah I found the examples very straightforward to follow (disclaimer - only did ecdsa.h but they all seem very similarly structured)
09:34 -!- Jello54 [~Jello@IGLD-84-229-44-23.inter.net.il] has quit [Ping timeout: 256 seconds]
09:34 < elichai2> siv2r[m]: I think there's a reason I didn't use getentropy but I can't remember it (been almost 2 years haha), I'll recheck later and respond to your comment
09:34 < robot-dreams> glozow: Interesting to see the `memory_cleanse` call / implementation in the bitcoin core version
09:35 -!- Azor [~Azor@190.79.223.248] has quit [Quit: Connection closed]
09:35 -!- Azor [~Azor@190.79.223.248] has joined #bitcoin-core-pr-reviews
09:35 -!- random_man [~random_ma@14.139.38.125] has quit [Ping timeout: 256 seconds]
09:36 < robot-dreams> nickler: The examples seem quite clear to me; they don't include (1) hashing the message or (2) exchanging public keys over a network (ECDH) but I think those are straightforward for a reader to infer from context
09:36 -!- leffw [~leffw@135.148.139.5] has joined #bitcoin-core-pr-reviews
09:36 < siv2r[m]> elichai2: sure, I have also mentioned this on GitHub, just in case
09:36 < michaelfolkson> I think was discussed before we started but why don't they include hashing the message? Replication of code between Core and libsecp?
09:37 < glozow> robot-dreams: indeed! https://github.com/bitcoin/bitcoin/blob/219d728fcbde8c313940788838afa46c2fb88762/src/support/cleanse.cpp#L17
09:37 < glozow> scary to think that the memset could be optimized out 😱
09:37 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has quit [Quit: Connection closed]
09:38 < leffw> Hi, I'm new here!
09:38 < glozow> leffw: welcome!
09:38 < robot-dreams> michaelfolkson: I'm guessing it's because we don't want to (1) take a dependency on a cryptography library, or (2) add a SHA256 implementation to the example code
09:38 -!- OliverOffing [~OliverOff@189.1.174.52] has quit [Quit: Connection closed]
09:38 < michaelfolkson> You don't want to move all hash functions to libsecp from Core presumably
09:38 < jimmysong> michaelfolkson: from the PR, I think it's to reduce dependencies? specifically a hashing library.
09:38 < b10c> agree that the examples are clear
09:38 < robot-dreams> It also seems Core and libsecp both have separate implementations of SHA256
09:38 < real_or_random> glozow: yes, and even more scary that we don't have a proper "cleanse" function in secp currently ^^
09:39 < real_or_random> (there's an open PR that I should update)
09:39 < theStack_> nickler: (re: arc4random vs getentropy on OpenBSD) yes i did. I'd rather assume that the mentioned projects are not following best practices. OTOH i don't think getentropy() is wrong either
09:39 < theStack_> (sorry for late reply)
09:39 < nickler> compared to the Core code it seems like the Schnorr examples do not specifically mention that the sig should be verified before giving it to the verifier.
09:40 < nickler> Which is very related to question 7:
09:40 < nickler> Is there anything missing in the examples (e.g. context_randomize, ec_seckey_verify, return value check, setting secrets to 0, etc…)?
09:41 < engraving> glozow what does it mean for "memset to be optimized out"?
09:41 < larryruane> engraving: if the compiler can determine that a variable isn't being read after a write, it can discard the write
09:41 < michaelfolkson> Is the idea that examples will show you *all* the "safe" uses? Or just to get you started using libsecp?
09:41 < glozow> engraving: i imagine that a compiler says "oh, you're setting this memory to 0 and then forgetting about it, there's no need to set it to 0"
09:42 < nickler> theStack_: I mean arc4 just sounds too scary to be used really... 
09:42 < jnewbery> nickler: good point about verifying the signature after signing. There's a recommendation in BIP340 to do that: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_note-14
09:42 < robot-dreams> engraving: here's a specific example where it gets optimized out. Note that in the assembly version, there is no `memset` call: https://godbolt.org/z/WeMfon6jh
09:42 < engraving> ohhhh compiler optimization -- I didn't realize. 
09:42 < elichai2> engraving: if you want to look for more information on this, this optimization is called "dead store elimination"
09:43 < jesseposner> calling secp256k1_sha256 from within the ecdsa example could be useful for documentation purposes, and it would also help emphasize the hashing requirement which can be a footgun
09:43 < nickler> jnewbery: yup, do you know if Core does the same for ECDSA?
09:43 < real_or_random> engraving: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/yang
09:44 < sipa> jnewbery: Bitcoin Core also does that, since recently.
09:44 < real_or_random> jesseposner: there's no sha256 in the public API
09:44 < theStack_> nickler: i think RC4 hasn't been used internally since OpenBSD 5.5. Nowadays arc4random doesn't have anything to do with RC4 anymore, it's a mnemonic for "A Replacement Call For Random" :D
09:44 < glozow> yeah https://github.com/bitcoin/bitcoin/blob/219d728fcbde8c313940788838afa46c2fb88762/src/key.cpp#L236
09:44 < jesseposner> real_or_random: ah
09:44 < nickler> theStack_: haha
09:44 < sipa> ha, a backronym
09:45 < theStack_> TIL from the man pages :D
09:45 < real_or_random> jesseposner: we should add new ECDSA signing function that hashes the message 
09:45 < larryruane> glozow: and that's probably not a performance-critical path, since we don't sign stuff that often, right?
09:45 < sipa> real_or_random: Once, or twice?
09:45 < engraving> thanks real_or_random Familiar with compilers breaking code's operating assumptions +1, grabbed this talk right before the link -- thanks!
09:45 < sipa> (Bitcoin's use of ECDSA uses double-SHA256)
09:45 < real_or_random> sipa: we should add it once :P
09:46 < sipa> real_or_random: Then my question is: for whom?
09:46 < Kaizen_Kintsugi_> noob question: what is exaclty this context? it looks like it is doing something to allocate memory?
09:46 < real_or_random> yeah, indeed, I don't know
09:46 < glozow> larryruane: i imagine it's more important to sanity-check that your signature is correct than try to save time. and yeah we don't sign nearly as often as we verify
09:46 < Kaizen_Kintsugi_> as in secp256k1_context
09:47 < siv2r[m]> nickler: the verification step happens for ECDSA too on the core
09:47 < siv2r[m]> https://github.com/bitcoin/bitcoin/pull/22934
09:47 < sipa> Kaizen_Kintsugi_: It used to hold a lot of precomputed tables to accelerate signing/verification, but since recently all those tables are now built-in to the binary at compile time.
09:47 < nickler> Ok perhaps a few sub questions: 1) what can happen if you don't check return value? 2) don't call seckey_verify 3) forget context_randomize?
09:47 < nickler> siv2r[m]: thx
09:47 < Kaizen_Kintsugi_> sipa: thanks
09:47 < sipa> So right now the context doesn't hold that much anymore; it holds randomization state as well as callbacks for errors, if you want to use that feature.
09:48 < Kaizen_Kintsugi_> randomization state = nonce that people refer to above?
09:48 < robot-dreams> Slightly different from the nonce
09:48 < Kaizen_Kintsugi_> ah
09:49 < glozow> sipa: so would `secp256k1_ecmult_gen_context`have precomputed multiplication tables?
09:50 < robot-dreams> The "randomization state" is a way to scramble your arithmetic operations to protect against side channel attacks that larryruane referenced
09:50 < sipa> The randomization state is for side-channel protection. It isn't observable/
09:50 < sipa> It helps blind intermediary values that are used, which are eventually cancelled out at the end.
09:50 < real_or_random> glozow: until recently, this struct had tables, yes and they would be created on context creation. now the tables are precomputed at build time (or actually in the repo) 
09:50 < Kaizen_Kintsugi_> crazy. Damn I have a lot to learn
09:51 < real_or_random> now `secp256k1_ecmult_gen_context`only holds the blinding data sipa is talking about
09:51 < glozow> real_or_random: i see, thanks
09:51 < sipa> https://github.com/bitcoin-core/secp256k1/blob/master/src/precomputed_ecmult_gen.c
09:51 < sipa> is the table
09:51 -!- skme [~skme@94.140.8.169] has quit [Quit: Connection closed]
09:51 < sipa> for signing
09:51 < sipa> verification has an even bigger one
09:52 < sipa> https://github.com/bitcoin-core/secp256k1/blob/master/src/precomputed_ecmult.c
09:52 < jimmysong> sipa: the precomputation is essentially some multiple of G, correct?
09:53 < glozow> was looking for those multiplication tables and couldn't find them. thought i'd see some magic like the minisketch linear transformation tables
09:53 < jesseposner> nickler: if you don't call seckey_verify, then you risk, with negligible probability, that the secret key is invalid because not all 256 bit numbers are valid secp256k1 keys (because valid secret keys are limited to scalars within the cyclical subgroup of the generator)
09:53 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:53 < sipa> jimmysong: That's correct, but kind of vacuously so... literally every point is a multiple of G ;)
09:54 < sipa> But indeed, they are lots of specific precomputed multiples of G.
09:54 < nickler> jesseposner: correct, with emphasis on negligible. So nothing will happen if you forget to seckey_verify for randomly generated keys
09:54 < sipa> If people are interested in what EC multiplication algorithms are actually used, we should do a separate review club on that (or probably several...).
09:55 < jules23> +1
09:55 < Kaizen_Kintsugi_> sipa: omg yes
09:55 < glozow> jesseposner: nickler: ooh can we do Q3 in further questions?
09:55 < nickler> and the answer to sub-question 2) above is perhaps obvious, you won't actually verify a signature in the worst case, ouch
09:55 < robot-dreams> sipa: I'd be very interested in ecmult session(s), can also host if no one else wants to
09:55 < jimmysong> the optimizations with the 8-bit words thing is insane
09:56 < nickler> glozow: ok!
09:56 < nickler> What is the probability that ec_seckey_verify fails given a uniformly random input byte string?
09:56 -!- jimmysong [~jimmysong@72-48-253-168.dyn.grandenetworks.net] has quit [Quit: Connection closed]
09:56 < robot-dreams> An intermediate interesting question IMO is, "what would cause it to fail"
09:56 < engraving> a bit off topic so ignore if need be: are we aware of active attempts of side channel attacks or are the precautions merely cause we know they have/can be done and so our implementations must use anti-side channel designs
09:56 < theStack_> i noticed that on the schnorr example, seckey_verify is not called. i guess this is just to save an extra call, since keypair_create checks whether the private key is valid anyways?
09:57 < glozow> nickler: i got an answer but i'm not sure if it's right
09:57 < glozow> it's = Probability(key > secp256k1 order) yes?
09:57 < glozow> and order is FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
09:57 < glozow> does that mean the chance is (0xFF - 0xEB) / 2^33 ?
09:57 < robot-dreams> engraving: I'm also curious about this question, e.g. what's a canonical scenario people have in mind when thinking about side channel (e.g. maybe a hardware wallet running secp256k1 code, an attacker stole it)
09:57 < siv2r[m]> jesseposner: nickler: in what order is this neglible probablity in? I tried calculating it like (p-n)/2^256. Here, p = field size and n = group order
09:57 < siv2r[m]> This comes around 1/2^128. This does not seem small when compared with 1/2^256
09:57 < sipa> 2^-128 is our security target.
09:58 < sipa> Anything below that is considered infeasible.
09:58 < glozow> oh it's 1/2^128?
09:58 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving]
09:58 < robot-dreams> glozow: Your reasoning looks reasonable but the calculated chance looks kind of large
09:58 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
09:58 < sipa> With ~2^128 operations, an attacker can compute the private key to a given public key already.
09:58 < stickies-v> the key also isn't allowed to be 0 iirc?
09:58 < real_or_random> extra question: what's the number of particles in the universe?
09:58 < nickler> stickies-v: correct
09:59 < elichai2> real_or_random: *observable universe ;)
10:00 < nickler> I think around 1/2^128 is a sufficiently close answer
10:00 < nickler> Ok, we're out of time, but I think we touched on the remaining questions
10:00 < siv2r[m]> oh, so this security target (2^-128) will become smaller and smaller as tech advances?
10:00 < Kaizen_Kintsugi_> Thanks nickler!
10:01  * glozow cries in exponential
10:01 < nickler> (or they're about build systems which isn't terribly exciting :D)
10:01 < sipa> The cryptography that Bitcoin uses assumes a 2^128 security level.
10:01 < Kaizen_Kintsugi_> This was a busy one wow
10:01 < jules23> 2^265 atoms  in observable universe?
10:01 < nickler> thanks everyone for participating.
10:01 < theStack_> thanks for hosting nickler!
10:01 < glozow> thanks nickler!
10:01 < sipa> Which is assumed to be infeasible for attackers for the forseeable - but not unlimited - future.
10:01 < emzy> Thank you nickler, glozow, real_or_random, elichai2, nickler, jesseposner_, robot-dreams, sipa and all.
10:01 < bitcoin1o1> thanks, nickler
10:01 < nickler> If you have more appetite for examples, we have a musig example here: https://github.com/ElementsProject/secp256k1-zkp/blob/master/examples/musig.c
10:01 < Kaizen_Kintsugi_> jules: its a lot smaller 
10:01 < effexzi> Thanks!
10:01 < ziggie> thanks
10:01 < nickler> Of course, the libsecp repo has many more open PRs! Some of them only require a bit of context to review. If you enjoyed today's session perhaps that's something for you.
10:01 < stickies-v> thank you for hosting nickler and elichai2 for the PR!
10:01 < jnewbery> thanks nickler! That was fascinating
10:01 < svav> Thanks all
10:01 < nickler> If you have any questions feel free to stop by #secp256k1
10:01 < jesseposner> Thanks!
10:01 < tarun> thank you nickler
10:01 < larryruane> thanks nickler and everyone else!!
10:02 < siv2r[m]> Thanks everyone!
10:02 < nickler> I have to go now, bye!
10:02 < michaelfolkson> Thanks nickler!
10:02 < b10c> Thanks!
10:02 < jules23> Kaizen_Kintsugi_ : quick look up on wolframalpha
10:02 < elichai2> Thanks nickler!
10:02 < robot-dreams> Thanks nickler!
10:02 < docallag> ty
10:02 < jules23> thanks
10:02 < Kaizen_Kintsugi_> oh thx for the correction
10:02 < glozow> #endmeeting
10:02 -!- tarun [tarun@gateway/vpn/protonvpn/tarun] has quit [Quit: Konversation terminated!]
10:02 -!- kalpa [~kalpa@ip-005-146-160-032.um05.pools.vodafone-ip.de] has quit [Quit: Leaving]
10:03 -!- Azor [~Azor@190.79.223.248] has quit [Quit: Connection closed]
10:03 < engraving> robot-dreams https://youtu.be/UNoP3qVyU8w are some interesting side channel attacks
10:03 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
10:03 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
10:03 -!- jules23 [~jules23@dyn-160-39-193-156.dyn.columbia.edu] has quit [Quit: Connection closed]
10:04 < engraving> obviously attackers aren't going to telegraph they're about to attack you but thought I'd float the question if anyone had seen any interesting attacks
10:04 < elichai2> Please feel free to reask any question that wasn't unanswered (there were so many observations and questions it was hard to follow haha) in the PR itself, in #secp256k1 or in private if you prefer :)
10:04 < engraving> thank you so much elichai2 
10:04 < glozow> very lively chat today, hope to see some of you again! please take a look at the upcoming meetings: https://bitcoincore.reviews/
10:04 -!- hemmetpizzle [~hemmetpiz@p54beb39a.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews
10:05 < michaelfolkson> A couple more shills. This tweet thread was great on different ways of generating entropy https://twitter.com/raw_avocado/status/1433408813596545027?s=20&t=ZUmPd-QYBGxw2XsGGQDyBQ
10:05 < glozow> next week is CPFP fee-bumping in packages
10:05 < sipa> engraving: So libsecp256k1 (on major platforms) should be completely free of timing attacks (all operations on secret data are constant time, have memory accesses and code paths that do not depend on secrets). For things like power leaks we rely on blinding.
10:06 < robot-dreams> michaelfolkson: You mean you didn't cut out 2048 little pieces of paper and draw them out of a hat?
10:06 < michaelfolkson> Plus jimmysong's book Programming Bitcoin is great if you need to learn from scratch about ECDSA signing etc https://github.com/jimmysong/programmingbitcoin
10:06 < engraving> sipa blinding of what specifically?
10:06 < sipa> engraving: introducing randomness into the algorithm early on in a way that gets cancelled out at the end
10:07 < michaelfolkson> Maybe Jimmy's book will have a Schnorr and MuSig section one day :)
10:08 < jesseposner> +1 to Jimmy's book. Also, this blog series is good for an elliptic curve crypto intro: https://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/
10:08  * engraving twists a towel, untwists a towel
10:08 < sipa> I shouldn't say we rely on blinding. libsecp256k1 (or probably, any pure-software system) cannot guarantee any protection against DPA or things like that, because who knows what an attacker can do if they can observe intermediary values in your CPU. Still, we use blinding for some best-effort to make it harder.
10:08 < engraving> yeah
10:08 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
10:09 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
10:09 < michaelfolkson> robot-dreams: I haven't used radioactive decay unfortunately. The Coldcard dice look cool. My entropy generation has been decidedly vanilla thus far
10:11 < michaelfolkson> And obviously entropy generator beware. Don't want anyone losing funds. Unbiased dice are fine though
10:12 < sipa> Because it is very cool, I need to mention Von Neumann debiasing here.
10:12 < engraving> yeah
10:12 < engraving> was just about to say that
10:12 < sipa> You can produce perfectly unbiased entropy using biased dice/coins.
10:13 < engraving> assuming the bias remains between flips
10:13 < sipa> Right, it assumes that every coin toss / die roll is an independent sample from the same distribution.
10:13 < engraving> +1
10:13 < michaelfolkson> If you combine it with an unbiased source? Or entirely biased sources?
10:14 < michaelfolkson> Ah seems the latter, ok
10:14 < alex_waltz> michaelfolkson haha thanks for sharing my tweet, however i think this one would have been more apropriate for the topic today. https://twitter.com/raw_avocado/status/1445024873382809604
10:14 < jesseposner> Apparently lava lamps are a decent source of entropy: the Cloudflare office in SF has a wall of them in their lobby: https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/
10:14 < engraving> sipa I guess debiasing also depends on the bias not being 100% :0
10:15 < sipa> engraving: I guess. It still works fine if that's the case, you'll just never finish :p
10:15 < engraving> VN extraction doesn't work with a coin that only hits head -- right?
10:15 < engraving> lol
10:15 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
10:15 < alex_waltz> jesseposner they actually have 3 sources the other 2 being a chaotic pendulum and also some radio active source.
10:15 < sipa> michaelfolkson: If you already have an unbiased source, I suggest you use just that.
10:16 < engraving> <g>
10:16 < michaelfolkson> Of course lol :)
10:16 < larryruane> sipa: "You can produce perfectly unbiased entropy using biased dice/coins" -- I love that, and it's interesting to observe that if the coin is SO biased that it's heads every time (probability 1.0), then the procedure never ends -- which makes sense, can't get a random result from (only) a deterministic input
10:16 < sipa> Trying to debias something else is way more work.
10:16 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
10:16 -!- leffw [~leffw@135.148.139.5] has quit [Ping timeout: 256 seconds]
10:16 < sipa> The basic VN algorithm only gets 25% of the entropy out, even if it is entirely unbiased already.
10:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Remote host closed the connection]
10:17 < sipa> There are more advanced versions that can extract more, though at increasing algorithmic complexity (and it quickly goes beyond what you'd want to do as a human).
10:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
10:17 < sipa> I created these tables once: https://github.com/sipa/writeups/blob/main/von-neumann-debias-tables/coin_extract_8rolls_15states.txt
10:18 < engraving> on the topic of quantifying the quality of entropy, I want to mention Kullback–Leibler divergence https://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_divergence
10:18 < sipa> That gets a bit over 50% out.
10:18 < engraving> sipa are you familiar with KL Divergence?
10:18 < sipa> yes, somewhat
10:19 < engraving> can think of it as encoding overhead
10:19 < engraving> cool
10:19 < michaelfolkson> alex_waltz: That's the tweet thread I was looking for, thanks
10:21 < engraving> I think of it as: I should see no KL_D between to an observed/sampled entropy corpus and if I do, it should at least be decreasing over time
10:22 < dome> that lava lamp article is really interesting!
10:23 -!- mninja [~sha@cpe-98-14-66-91.nyc.res.rr.com] has left #bitcoin-core-pr-reviews []
10:25 -!- engraving [~engraving@195.181.160.173.adsl.inet-telecom.org] has quit [Ping timeout: 256 seconds]
10:25 < michaelfolkson> glozow: Please include an extended converation log in the meeting nodes. Want to read all these links!
10:26 < michaelfolkson> *notes
10:26 -!- JDuse [~JDuse@81.29.24.126] has quit [Quit: Connection closed]
10:41 -!- alex_waltz [~alex_walt@217.146.82.84] has quit [Quit: Connection closed]
10:56 < robot-dreams> Wow review club is so organized, scheduled out until late March!!
10:57 < robot-dreams> sipa: What do you think a suitable session (or series) related to ecmult might look like? I don't know if diving in directly with something like https://github.com/bitcoin-core/secp256k1/pull/1058 would be viable
10:59 < sipa> Yeah I think 1058 is too much to start with.
11:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Remote host closed the connection]
11:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
11:23 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
11:26 -!- Clint65 [~Clint@68-255-237-145.lightspeed.hstntx.sbcglobal.net] has quit [Quit: Connection closed]
11:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Remote host closed the connection]
11:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
11:54 -!- sanya [~sanya@79-101-150-15.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
12:04 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:08 -!- dome [~textual@50-250-87-150-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
12:08 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
12:08 -!- effexzi [uid474242@ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:27 -!- effexzi [uid474242@ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
12:34 -!- javed [~javed@103.176.140.6] has quit [Quit: Client closed]
12:45 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
12:45 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
12:46 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
12:47 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit]
12:48 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
12:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 250 seconds]
13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 240 seconds]
13:12 -!- Netsplit *.net <-> *.split quits: dumeril[m], hebasto, jomat, sdaftuar, Zenton, jarolrod, lightlike, jamesob, johnzweng, RubenSomsen,  (+92 more, use /NETSPLIT to show all of them)
13:13 -!- Netsplit over, joins: achow101, hugohn, sandipndev, stick[m], dongcarl, Henry151, pinheadmz, nickler, S3RK, larryruane (+6 more)
13:13 -!- Netsplit over, joins: uasf_, michaelfolkson, _aj_, takinbo, robertspigler, laanwj, real_or_random, harding, qubenix, emzy (+5 more)
13:14 -!- Netsplit over, joins: RubenSomsen, ajonas, glozow, jkczyz, blkncd, sanket_cell, MatrixBot12, dr-orlovsky, yakshaver, jrawsthorne (+8 more)
13:14 -!- Netsplit over, joins: Zenton, jesseposner, gleb7454386, grettke, yonson, svav, bitcoin1o1
13:14 -!- Netsplit over, joins: schmidty, willcl_ark, kcalvinalvin, stickies-v, raj, sipa, neha_, josibake
13:14 -!- Netsplit over, joins: hebasto, tralfaz, Common, adiabat, ziggie, dhruv, m011, hemmetpizzle
13:15 -!- Netsplit over, joins: kanzure, fjahr, _0x0ff, windsok, stick, realtbast[m], jonasschnelli, merkle_noob[m], livestradamus, vincenzopalazzo (+5 more)
13:15 -!- Netsplit over, joins: dunxen, ghost43
13:15 -!- Netsplit over, joins: waxwing, sdaftuar
13:15 -!- Netsplit over, joins: FelixWeis, notmandatory_, elichai2, dergoegge
13:15 -!- Netsplit over, joins: ryanofsky, b10c, jamesob, fanquake, provoostenator, johnzweng, amiti
13:15 -!- rex_123[m] [~rex123mat@2001:470:69fc:105::1:83a2] has quit [Ping timeout: 245 seconds]
13:15 -!- George[m] [~georgezen@2001:470:69fc:105::1:5d4a] has quit [Ping timeout: 250 seconds]
13:15 -!- willcl_ark [~willcl-ar@user/willcl-ark/x-8282106] has quit [Ping timeout: 240 seconds]
13:15 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 240 seconds]
13:15 -!- siv2r[m] [~siv2rmatr@2001:470:69fc:105::fed3] has quit [Ping timeout: 260 seconds]
13:15 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Ping timeout: 252 seconds]
13:15 -!- dumeril[m] [~dumerilma@2001:470:69fc:105::1:6806] has quit [Ping timeout: 252 seconds]
13:15 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Ping timeout: 245 seconds]
13:15 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has quit [Ping timeout: 245 seconds]
13:15 -!- jomat [~jomat@2001:470:69fc:105::21] has quit [Ping timeout: 245 seconds]
13:15 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has quit [Ping timeout: 245 seconds]
13:15 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has quit [Ping timeout: 250 seconds]
13:16 -!- Murch [~murch@user/murch] has quit [Ping timeout: 260 seconds]
13:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
13:17 -!- uasf_ [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
13:32 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined #bitcoin-core-pr-reviews
13:32 -!- sipa [~sipa@user/sipa] has joined #bitcoin-core-pr-reviews
13:32 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has joined #bitcoin-core-pr-reviews
13:32 -!- rex_123[m] [~rex123mat@2001:470:69fc:105::1:83a2] has joined #bitcoin-core-pr-reviews
13:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Remote host closed the connection]
13:53 -!- Murch [~murch@user/murch] has joined #bitcoin-core-pr-reviews
14:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
14:11 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has quit [Ping timeout: 256 seconds]
14:12 -!- hemmetpizzle [~hemmetpiz@p54beb39a.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
14:14 -!- willcl_ark [~willcl-ar@2001:470:69fc:105::1:620a] has joined #bitcoin-core-pr-reviews
14:15 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #bitcoin-core-pr-reviews
14:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c98c:16e0:a06f:367a] has joined #bitcoin-core-pr-reviews
14:26 -!- jomat [~jomat@2001:470:69fc:105::21] has joined #bitcoin-core-pr-reviews
14:27 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te3w1r7ppltaav7.ipv6.telus.net] has quit [Remote host closed the connection]
14:28 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has joined #bitcoin-core-pr-reviews
14:28 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te7f132jpeve0il.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
14:29 -!- dumeril[m] [~dumerilma@2001:470:69fc:105::1:6806] has joined #bitcoin-core-pr-reviews
14:33 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te7f132jpeve0il.ipv6.telus.net] has quit [Ping timeout: 256 seconds]
14:39 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2001:56a:7c7c:8800:f113:caef:4f7e:c11d] has joined #bitcoin-core-pr-reviews
14:40 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
14:41 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #bitcoin-core-pr-reviews
14:41 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #bitcoin-core-pr-reviews
14:43 -!- George[m] [~georgezen@2001:470:69fc:105::1:5d4a] has joined #bitcoin-core-pr-reviews
14:50 -!- siv2r[m] [~siv2rmatr@2001:470:69fc:105::fed3] has joined #bitcoin-core-pr-reviews
15:16 -!- docallag [~docallag@2a02:8084:90e2:3a80:1cf0:5fbd:eef0:c61c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
16:34 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
16:42 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
17:00 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
17:48 -!- effexzi [uid474242@ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
18:05 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
18:15 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
18:16 -!- inersha [~in3rsha@185.204.1.225] has quit [Remote host closed the connection]
18:19 -!- bitcoin1o1 [~bitcoin1o@189.132.107.48] has quit [Ping timeout: 256 seconds]
18:38 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
18:44 -!- skme [~skme@94.140.8.171] has joined #bitcoin-core-pr-reviews
18:52 -!- skme [~skme@94.140.8.171] has quit [Quit: Connection closed]
18:57 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
19:10 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
19:11 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
19:13 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
19:22 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
19:27 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
19:28 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
19:53 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
19:53 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
20:01 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
20:07 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
20:12 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
20:18 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
20:45 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
20:45 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
20:46 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
21:17 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:34 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
21:36 -!- DonFlamingo [~DonFlamin@cpe-67-49-78-121.dc.res.rr.com] has joined #bitcoin-core-pr-reviews
21:37 -!- DonFlamingo [~DonFlamin@cpe-67-49-78-121.dc.res.rr.com] has quit [Client Quit]
22:01 -!- yonson [~yonson@ip68-105-113-161.sd.sd.cox.net] has quit [Read error: Connection reset by peer]
22:01 -!- yonson [~yonson@2600:8801:d900::16db] has joined #bitcoin-core-pr-reviews
23:25 -!- Netsplit *.net <-> *.split quits: dergoegge, gleb7454386, FelixWeis, notmandatory_, elichai2, jesseposner, Zenton
23:28 -!- Netsplit over, joins: Zenton, FelixWeis, notmandatory_, jesseposner, gleb7454386, elichai2, dergoegge
--- Log closed Thu Feb 03 00:00:48 2022