--- Log opened Sun Jun 20 00:00:43 2021
07:14 -!- nsh is now known as EmmyNoether
07:16 -!- EmmyNoether is now known as nsh
08:53 < real_or_random> yep we should make contexts precomputed
08:53 < real_or_random> we just need someone to work on it (like in 95% of the other cases :))
08:54 < real_or_random> nickler: yeah now you'll need to make a video for the musig2 rom proof :P 
08:54 < roconnor> how do you make contexts precomputd?
08:54 < real_or_random> roconnor: what obstacle do you see? the randomization?
08:56 < roconnor> The enormous size of a .c files with a table of coordintes written in ASCII or the need to generate object files on a per architecture basis.
08:57 < real_or_random> sipa: couldn't you have a read-only context in the main thread and whenever  you spawn a thread, clone that one into the new thread? (not sure if that's simpler)
08:57 < real_or_random> roconnor: well yeah, the source file will be enormous but I don't think that will be a real issue
08:58 < real_or_random> hm I think we had some numbers somewhere 
09:01 < roconnor> ISO/ETC 9899:TC3 5.2.4.1 says "max 65535 byes in an object (in a hosted environment only)".  Though I'm half joking in pointing this out.
09:03 < real_or_random> hehe
09:03 < roconnor> I think violating these limits just means the compiler might fail.  I doubt it is a licence to do anything else.
09:05 < real_or_random> common all our code has UB anyway because our identifiers are too long :)
09:05 < roconnor> anyhow, if the .c file isn't too big, then it is okay with me.
09:05 < real_or_random> https://github.com/bitcoin-core/secp256k1/pull/918#issuecomment-818673827 here are some numbers but they don't matter because we multi-comb 
09:05 < real_or_random> (as sipa points out below my comment)
09:07 < real_or_random> and here is the actual issue about precompuation https://github.com/bitcoin-core/secp256k1/issues/893
09:09 < roconnor> Right, I've only been thinking about the ecmult context (for verification).
09:10 < roconnor> that could be replaced with a const global variable.
09:55 < gmaxwell> roconnor: The same way that signing is static. The files are portable (there are seperate ones for each field implementation).  There is a PR I did to do it for smaller contexts, but it can be done for larger, the files are just big.
09:57 < gmaxwell> It's better to have one static copy in the library than potentially many copies in ram.  (and esp when targeting embedded systems, since the static copies end up in memory mapped flash and take no ram at all)
09:59 < sipa> the precomputed table file only depends on ecmult parameters, not on field impl
09:59 < sipa> it uses macros to define constant field element initializers
09:59 < sipa> and those macros are field impl specific, but the table code isn"y
10:12 < gmaxwell> derp indeed.
10:22 -!- jesseposner [~jesse@2601:647:0:89:ec38:1bfb:5fdf:9317] has quit [Ping timeout: 244 seconds]
10:23 -!- jesseposner [~jesse@2601:647:0:89:49f9:36c0:e98a:a6be] has joined #secp256k1
12:13 < real_or_random> gmaxwell: are there embedded devices on which people would normally prefer to have the context in RAM instead of flash? or do you think that would be a niche thing
12:25 -!- sipa [~pw@user/sipa] has quit [Remote host closed the connection]
12:28 < gmaxwell> real_or_random: I don't think that would ever be desirable on a device that has memory mapped flash in the first place-- the flash is as fast as ram to read, and spares your ram.
12:28 < gmaxwell> real_or_random: but if you did care, I believe you can just tag the object to be placed in another segment.
12:29 < gmaxwell> The more common thing people would want is to choose a smaller setup.  Particularly, in a hardware wallet that hardly every validates things anyways, a giant ecmult table is silly. (and the default is larger than the flash on most of these devices, too)
12:30 < gmaxwell> If someone was really strapped for flash space, I think they'd just prefer a small table rather than computing it at runtime.
12:31 < gmaxwell> This is partially because the table grows exponentially in size for a linear speedup, so a table much smaller isn't that much slower.
12:38 -!- sipa [~pw@user/sipa] has joined #secp256k1
12:59 < gmaxwell> real_or_random: I think the real case where someone would want an in-memory version is if they needed to support generator flexiblity. But other than stuff like pedersen commitments I don't think we've seen any need/interest in that.
14:37 < gmaxwell> I posted sipa's safegcd writeup on HN,  its on the second page of newest right now, if you want to upvote (not linking the article becuase HN has anti-upvote brigade hurestics that get triggered by upvotes to direct links)
17:06 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
17:10 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:17 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
17:22 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
21:03 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #secp256k1
21:04 -!- jessepos_ [~jesse@2601:647:0:89:6de9:9aa6:8bb7:1691] has joined #secp256k1
21:09 -!- Netsplit *.net <-> *.split quits: luke-jr, jesseposner, sipa
21:09 -!- lukedashjr is now known as luke-jr
21:09 -!- Netsplit over, joins: sipa
22:15 -!- uasf_ [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
22:16 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined #secp256k1
--- Log closed Mon Jun 21 00:00:44 2021