--- Log opened Tue May 04 00:00:45 2021
02:23 < real_or_random> yeah, let's do this, reducing the macOS jobs was anyway on my mental list...
02:24 < real_or_random> I think we could reduce them drastically, That's still x86_64 and gcc/clang, there's not so much difference in the end.
02:26 < real_or_random> running only against master: that's another good idea, that's kind of similar to my idea of nightly runs.
06:55 < elichai2> gmaxwell: arghh I can't pad a bip39 word with NULLs without leaking its length
06:58 < andytoshi> you can fit every bip39 word into 4 characters uniquely
06:58 < andytoshi> by taking a prefix, or suffixing '-' for short one
06:59 < andytoshi> though i agree with your point that if the goal was to have unique 4-char prefixes, why tf are there words that are 3 characters
06:59 < gmaxwell> elichai2: you pad the entire list when you load it.
06:59 < gmaxwell> the list itself isn't secret data.
07:00 < elichai2> I mean the input strings
07:00 < elichai2> when you do mnemonic->entropy
07:00 < elichai2> the entropy->mnemonic I already implemented in constant time
07:00 < gmaxwell> bip39 doesn't decode the mapping ... it hashes the string, it's fundimentally a brainwallet format.
07:01 < elichai2> oh you're saying I can just not support the other way around because it's not really needed, interesting
07:01 < elichai2> well at the very least it's needed to verify the checksum
07:02 < sipa> there is no other direction
07:02 < roconnor> elichai2 is saying to verify the checksum, the words have to be converted to their binary representatives.
07:02 < sipa> oh i see
07:03 < elichai2> the checksum is on the entropy data right? so if you want to verify the checksum you need to convert the words back to the original entropy data
07:03 < elichai2> roconnor: exactly
07:03 < gmaxwell> oh. I thought the checksum was accomplished by sha256ing the words too?
07:03 < gmaxwell> damn.
07:03 < elichai2> nope, it's on the raw data
07:03 < roconnor> elichai2: what is your input representation?
07:03 < elichai2> either a string "first second third" or a list of the words
07:04 < gmaxwell> wait ... that means you can't check the checksum without having the same wordlist. yeah I bet lots of things never check the checksum.
07:04 < elichai2> gmaxwell: yes
07:04 < roconnor> elichai2: list of words? What language are we programming in?
07:04 < elichai2> this in Go but we can talk in C if you prefer
07:05 < elichai2> in C it will be a char**  a size_t* and an enum for 12/15/18/21/24 words
07:05 < roconnor> elichai2: if your words are in a string that is space delimited then you can pad your wordlist with spaces instead of words.
07:05 < roconnor> I mean spaces instead of nulls.
07:06 < elichai2> actually scratch the size_t* in C it will be NULL terminated probably
07:07 < elichai2> roconnor: hmm but if its a single between each word then it's not enough, I padded the whole wordlist to 8 bytes per word, I still need to somehow make the input words 8 bytes each
07:07 < roconnor> oh.
07:07 < elichai2> and it looks like it's not possible without leaking their lengths. unless I do some UB like reading 8 bytes ignoring NULL ends and comparing the full 8 bytes
07:08 < gmaxwell> so you can make a little machine that works one byte at a time over the input buffer, and has a length padded output buffer, and for the n-th byte of the input it touches outlen-n bytes of the output.
07:09 < elichai2> (it can be non UB via checking cache-lines/alignment + assembly, but maybe Go's strings are always aligned or something)
07:09 < gmaxwell> and using state variables decides which output byte its actually updating.
07:10 < gmaxwell> elichai2: there is no such thing as 'not possible' for constant time... you can make a whole virtual cpu constant time.  The only thing that makes it impossible to make something constant time is being unable to compute a hard upper bound on the runtime. :P
07:10 < sipa> right, turn it into a per-byte loop that using constant-time logic handles both processing a character in a word, or transitioning to the next word
07:11 < roconnor> Doesn't this still all leak the size of the input buffer?
07:11 < sipa> edit: or deals with the at-end-of-string case
07:11 < gmaxwell> well you know an upper bound on that.
07:11 < sipa> ah, but memory access patterns will depend on the input length
07:12 < roconnor> right, but in C you cannot access outside the bounds of the input array legally.
07:12 < sipa> unless you first put it in a constant-size buffer
07:12 < gmaxwell> Caller has to write into memory you provide. :P
07:12 < sipa> but doing so itself will leak the skze
07:12 < roconnor> right I think fixing up the interface to require the caller fill in the allocated memory would be better.
07:12 < roconnor> though that is maybe just asking someone else to not be constant time.
07:13 < gmaxwell> (or just require the caller to provide a (max_word_len+1)*total_words buffer)
07:13 < roconnor> Maybe it's better to operated on 4 character words afterall?
07:14 < gmaxwell> for decode you could.
07:14 < roconnor> thanks to null-termination bytes, even 3 letter words are 4 characters in C.
07:14 < roconnor> or space delimited.
07:16 < elichai2> yeah memcmping into the fixed sized buffer leaks the original length
07:16 < elichai2> roconnor: idk if that really helps, because chances are the caller will just do that same memcpy
07:17 < elichai2> *memcpying
07:17 < roconnor> memcpying 4 bytes does not.
07:18 < sipa> well there is fundamentally no way to write a constant-time algorithm that processes an (entire) variable-size input
07:18 < elichai2> `elichai2> and it looks like it's not possible without leaking their lengths` `gmaxwell>there is no such thing as 'not possible' for constant time`
07:18 < elichai2> :)
07:18 < sipa> unless you exclude memory access patterns of that input
07:19 < elichai2> sipa: what do you mean by "memory access patterns"?
07:20 < roconnor> constant time usually doesn't mean constant time, but rather branchless and constant memory access, or something like that.
07:20 < sipa> indeed
07:21 < sipa> elichai2: the order in which certain bytes of memory are accessed needs to be independent of the secret in a constant-time algorithm
07:21 < sipa> if the length of your input itself is secret, that's a problem
07:21 < gmaxwell> I said above, you require the caller to provide the buffer at the right size.
07:22 < sipa> yeah, then there is no problem, but you're likely making the caller leak their length
07:22 < elichai2> but then they'll probably leak the lengths themselves
07:22 < sipa> on the other hand, if the caller is a GUI, they're leaking everything already
07:23 < gmaxwell> obviously if he's getting data from the user the _user_ might be non-constant time, but as I said before this spec was bad because it was easy to use incorrectly. :P just another example.
07:23 < elichai2> I also thought about that, not just GUI but stdin, and all kernel buffers probably leak the lengths of everything anyway
07:23 < gmaxwell> Clearly the way the user input should work is that you can type in exactly one character per minute, on the minute, for the maximum length (just hit space after you hit the maximum. :P )
07:24 < elichai2> so I guess the best I can do is leak the length of the whole thing but not leak the length of each word
07:24 < gmaxwell> elichai2: buffers? read one character at a time.
07:24 < elichai2> gmaxwell: loool
07:24 < roconnor> come on.  The space bar has a distinct clicking sound.
07:24 < gmaxwell> fine, random characters after the maximum and it ignores them.
07:24 < sipa> you're required to type on two keyboards simultaneously
07:24 < sipa> either "1" on one and "0" on the other
07:25 < sipa> or the other way around
07:25 < elichai2> roconnor: just lube it
07:27 < gmaxwell> the (re?) realization that the checksum requires reversing the encoding process further convinces me that nobody actually uses this thing safely.
07:27 < elichai2> yeah, I looked at all the bip39 impls i've found and none of them even attempted to make the slightest thing to make it safer
07:29 < roconnor> I still don't follow what's wrong with copying 4 characters from each word?
07:29 < gmaxwell> (because needing the list to check the checksum is incompatible with the design feature that the user can use their own wordlist... which means that checksum failure is normal and expected)
07:30 < elichai2> roconnor: what do you do if a word is 5 characters?
07:30 < roconnor> elichai2: ignore the 5th character.
07:31 < elichai2> I'll need to check that no 2 words share the same 4 first characters, but that's probably true
07:31 < gmaxwell> you tell the user to only enter the four characters per word.
07:31 < gmaxwell> elichai2: thats a requirement of the bip.
07:32 < elichai2> oh you're right
07:32 < roconnor> If they user enters a word that is strictly less than 3 characters then you can flag that as a non-secret error.
07:32 < elichai2> that's a very interesting idea
07:33 < roconnor> I think it is maybe okay to leak the fact that the entered word isn't long enough to be valid.
07:35 < elichai2> i'll accept the full mnemonic as a space separated string, and then operate on 4 letters at a time and using constant time magic "ignore" every sequence that doesn't come after a space
07:35 < elichai2> it will still leak the full length at the user side but that's a price I think i'm willing to pay for the UX, instead of asking the user to enter the first 4 letters of every word
07:36 < roconnor> actually there is a bit of an issue here.
07:36 < roconnor> the full words are hashed to produce the entropy
07:37 < roconnor> and I was suggesting that the checksum only check the first 4 letters of each word.
07:37 < gmaxwell> once you've decoded the entropy you reencode into words.
07:37 < roconnor> Right, you cannot rely on the words that the user enters; only the first 4 letters.  You have to reconstruct the phrase.
07:37 < gmaxwell> hopefully the min and max length are such that the hashing isn't variable time.
07:37 < roconnor> ha ha ha ha
07:38 < gmaxwell> the shortest word is three characters, longest is 8 .. (so 4 and 9 with the spaces) -- so actually probably not.
07:38 < roconnor> well, you can run all possible sets of block lengths.
07:38 < gmaxwell> yeah
07:38 < gmaxwell> and cmove the state.
07:38 < gmaxwell> lol
07:39 < sipa> you can make a constant-time 1-byte incremental sha256
07:39 < sipa> which also accepts "nothing" as input
07:40 < roconnor> ... so I've been thinking about a bech32-like master secret with a bech32-like checksum ...
07:40 < roconnor> and bech32-like SSS
07:41 < roconnor> maybe you'd rather just design this than deal with BIP39... :)
07:42 < elichai2> roconnor: I have the full words and can hash them without exposing each individual word length
07:43 < elichai2> so the pbkdf means that we have to leak the length of the full mnemonic sentence
07:43 < sipa> elichai2: not necessarily
07:43 < elichai2> *I think*
07:43 < gmaxwell> no, you can make the hashing constant time.
07:43 < roconnor> [10:38] <roconnor> well, you can run all possible sets of block lengths.
07:44 < roconnor> [10:38] <gmaxwell> and cmove the state.
07:44 < elichai2> wops should've read the full thing before I've commented
07:44 < sipa> (well, apart from the memory access pattern again of course if you use a variable-sized input buffer)
07:44 < gmaxwell> it just always runs for the maximum number of input compression funciton runs and skips the pointless ones.
07:45 < roconnor> the final block operation in sha256 is an xor.
07:45 < roconnor> you can czero that out.
07:46 < gmaxwell> sipa: I'd assume that he'd decode the entropy again into a fixed size form. and then have a function that constant time copies it into the appropriate sha256 compression function inputs.
07:48 < elichai2> I'm starting to think it's better to just skip verifying the checksum :P
07:49 < elichai2> roconnor: I'm still waiting for bech32 private keys :)
07:49 < roconnor> I think verifying the checksum is moderately important.  Not sure what you are doing.
07:49 < roconnor> elichai2: private keys or master secrets?
07:49 < elichai2> maybe I should write a new bip to replace bip39 lol. but that's probably a little too late
07:49 < gmaxwell> not verifying it has the property that if you type the input wrong once and generate addresses you won't be able to get them back later. Sweet, enh?
07:49 < elichai2> roconnor: even just simple private keys
07:50 < gmaxwell> there are already multiple bip39 alternatives.
07:50 < elichai2> gmaxwell: is that a feature or a bug? ;)
07:50 < gmaxwell> e.g. electrum doesn't use bip39 because bip39 isn't versioned, so they couldn't encode what wallet type is in use.
07:51 < elichai2> really? what does electrum use?
07:51 < roconnor> what would it mean for bip39 to be versioned?
07:52 < gmaxwell> https://electrum.readthedocs.io/en/latest/seedphrase.html
07:52 < gmaxwell> roconnor: there is no metadata, only entopy. So you can code something to tell you what derrivation path(s) you're using, what scriptpubkey types, etc.
07:52 < elichai2> it sounds like in practice it's not almost the same as bip39 but with some metadata
07:52 < elichai2> *it's almost the same
07:53 < elichai2> no, sorry, just the same wordlist
07:54 < roconnor> gmaxwell: the metadata isn't secret right, so it can be copied widely and kept insecurely?
07:54 < gmaxwell> Yes, but if you lose it or mismatch it, you can't recover your funds, so it would be kind of crazy to not preserve it with the private key.
07:57 < roconnor> Right. I get that.  But secure storage, in a cryptosteel capsule or whatever has only a limited space.  So this metadata needs to be concise if it is going to literally be stored with the master secret.
07:58 < roconnor> And if we are doing 2 of 3 you need to store the public keys of the other 2 and construction and keep the master entropy really secret.
07:58 < roconnor> This seems tough to do well.  I don't really have an answer.
07:58 < gmaxwell> sounds like cryptosteel isn't the best idea. :P
07:59 < roconnor> ha, do you have a best idea?
08:00 < gmaxwell> Not really.
08:01 < roconnor> The best I've come up with is storing the master secret entropy in your favorite cryptosteel and then copies of the non-secret data it lots of places, including a copy next to your cryptosteel.
08:02 < belcher> descriptors need their own encoding really, its not ideal for users to be writing down weird strings including paranthesis, apostrophes and slashes
08:03 < belcher> a nice benefit of of seed phrases is the user can write them without a printer that might possibly save the info in an internal disk, so how about encode descriptors into mnemonic words too
08:03 < belcher> worth noting, if you use n-of-n multisig the problem of saving separate pubkeys/descriptors goes away
08:06 < gmaxwell> what is the obsession with mnemonic words? They take longer to enter than other strings, for a given amount of data.
08:07 < roconnor> I'm definitely not obseed with mnemonic words.  I want to use the bech32 alphabet.
08:08 < belcher> words have a lot of error correction (fair enough bech32 does as well), and they _might_ be more user friendly for complete newbs since they're regular words (though this should be checked)
08:09 < gmaxwell> roconnor: FWIW, a better selection of permutation may be possible-- shortly after we published BIP173 someone published a very nice character/character confusion matrix generated from passwords on some large websites.
08:09 < gmaxwell> belcher: bip39 words don't have much/any erorr correction once you've dropped them to 4 letters though, which any encoding on cryptosteel/etc does.
08:10 < roconnor> gmaxwell: think it is better enough to warrent another standard?
08:11 < gmaxwell> roconnor: well you may need another standard anyways due to length, and/or because for storing a private key where error _correction_ is actually useful, more checksum data may be appropriate.
08:11 < belcher> error correction from bad handwriting, because they're actual words they can still be read (though yes agreed cryptosteels are rubbish)
08:11 < gmaxwell> belcher: there are a lot of posts about people trying to figure out what they wrote down, though it might be due to wide use.
08:11 < roconnor> I definitely want a longer BCH code than BIP173 has.
08:12 < gmaxwell> roconnor: yeah then you can change the permutation for ~free.
08:12 < roconnor> I guess that is true.
08:13 < gmaxwell> fwiw, I found some good BCH codes for 8degree checksums a while back. mostly to make fun of the bcash thing that managed to pick not very good values.
08:13 < roconnor> Bech32 BCH style codes has the covenent property that you can create SSS shares with a valid BCH checksums when the original secret has a valid BCH checksum.
08:14 < gmaxwell> roconnor: yes, thats cute but I'm not sure that it's important: the shares could just be individually checksummed and decoded before combining. :)
08:15 < roconnor> It makes it easier when are using a paper computer: https://github.com/roconnor-blockstream/SSS32
08:15 < roconnor> (not constant time)
08:15 < gmaxwell> In any case, so for deg8 it's still possible to find much better bch codes than typical through search. Dunno if thats true at higher degree.
08:16 < sipa> for private key materia you probably want a longer code anywah
08:17 < gmaxwell> 8 is already longer than 6, but yeah, I dunno how long someone would want. The tradeoff is pretty different.
08:17 < roconnor> I'm a little hung up on how long of a BCH code you would want for a master secret, and how many bits of entropy you want for the master secret.
08:18 < roconnor> The nice thing about longer entropy is that it helps compansate for biased dice or whatnot.
08:18 < sipa> roconnor: that's the hard question :)
08:19 < gmaxwell> oh because you want to do this on paper you don't want to do something like generate your master secret from 2x dice throw then hash them?
08:19 < gmaxwell> obviously you need sipa's dice whitening state machine tables.
08:20 < roconnor> I mean I'd store the master secret from the dice, and I would expect hashing to be a first step in some sort of HD derivation thing.
08:20 < roconnor> gmaxwell: that's true actually.  Maybe short entropy with bias correction is best.
08:20 < roconnor> Now that you mention it, I wanted to see if I could build a board game out of sipa's tables.
08:20 < gmaxwell> roconnor: right but except for using some paper scheme why not store the whitened entropy. E.g. dice->hashing->store
08:21 < roconnor> Are we talking about paper hashing?
08:21 < gmaxwell> I suppose even on paper, 'hashing' could be just sipa's tables.
08:23 < gmaxwell> if you eschew any kind of bip32 thing and work with single keys you can generate your key on paper, SSS on paper... then generate the pubkeys from the shares using untrusted but independant computers... and combine them. :P
08:23 < roconnor> okay I'm definitely on board with this whitening idea.  The shorter the master secret the easier it is to keep safe and secure.
08:23 < elichai2> gmaxwell: imho mnemonics are much less scary for new users and non-technical people
08:23 < roconnor> I'm not convinced I can to elliptic curve math on paper.
08:24 < roconnor> *can do
08:24 < gmaxwell> elichai2: I don't think that is clear, also 'less scarry' isn't necessarily good if it causes them to not understand that their private key is important.
08:25 < gmaxwell> You get bct posts where people only wrote down one word from their seed because they didn't understand they needed all 12.  Or where people were confused because of some words that were in the wordlist.
08:26 < gmaxwell> roconnor: you don't have to. That was my point. If you encode just a single private key and then secret share it on paper... Then use computers to turn them into pubkey keys... you can interpolate the public keys to get the shared public key. :P
08:26 < elichai2> I haven't argued the "error correction" property, just that it's less scary. but you're arguing less scary may be a disadvantage, idk about that
08:26 < roconnor> oh I misread you.  generating pubkey on independent computers.  Right, but at that point they can just do the bip32 thing.
08:26 < gmaxwell> roconnor: huh?
08:27 < roconnor> Sorry I'm responding out of sync with you.
08:27 < elichai2> roconnor: I want to see you doing the full HMAC-SHA512 from bip32 on a piece of paper :P
08:27 < gmaxwell> elichai2: Private keys are scary. Making them look unimportant doesn't do users a service.  And making it look like words has other bad effects, like users not copying the whole thing.
08:27 < elichai2> but arguably much easier than ec math
08:28 < roconnor> Just mean that if you are using computers to turn secrets into pubkeys, then they might as well do HD stuff right?
08:28 < gmaxwell> elichai2: in any case, if anyone really wants to argue easier for users its something that probably should be studied rather than assumed... otherwise it's just very subjective.
08:28 < roconnor> elichai2: The only thing I'm willing to do so far on paper is SSS interpolation and BCH code creation/checking.
08:28 < gmaxwell> roconnor: you can't do HD stuff in a split secret way. :)
08:29 < roconnor> ooooh but you can do it with single keys.
08:29 < roconnor> wow
08:29 < gmaxwell> I thought you'd be amazed. I'm dubious that it's actually that useful, but ... :)
08:30 < roconnor> ah no, I've been splitting keys up over GF_32, not GF_some_large_prime.
08:31 < roconnor> Like maybe I could do that math on paper ...  I haven't tried yet ... and you won't get the bch checksum properties that we get with working over GF_32.
08:31 < gmaxwell> ah right, can't preserve the bech32 checksum and have the secret sharing hold over to the curve. You've got me there.
08:31 < elichai2> roconnor: unrelated fyi, idk how works on libwally in blockstream but kodus, they're the only one with a somewhat sane and simple(as much as can be) bip39 implementation, all the rest use big ints and bit vectors
08:31 < sipa> are you saying we need to design a cryptosystem whose private key space is GF(32^k)?
08:31 < roconnor> cool to hear.
08:31 < roconnor> sipa: that might be good.
08:32 < roconnor> oh no.  I thought this channel was bitcoin-wizards.
08:32 < gmaxwell> sipa: sadly weil descent is an issue with high extension fields.
08:32 < roconnor> Sorry for going off topic.
08:33 < gmaxwell> I mean it's normally dead in any case.
08:34 < elichai2> yeah and I'm the one who started with the off-topic bip39 conv
08:43 < roconnor> This has been helpful.  Seems like my next step is to design "sipa: the board game".
08:45 < elichai2> `# Make sure the mnemonic we generate is not also a valid bip39 seed by accident. Note that this test has not always been done historically,  so it cannot be relied upon.`
08:45 < elichai2> lol, that's from electrum's code of their own mnemonics standard
10:59 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-sgxqoxzgamtopsll] has quit [Ping timeout: 258 seconds]
11:00 -!- digi_james [sid281632@gateway/web/irccloud.com/x-bnvrcpkdhkxgxzpl] has quit [Ping timeout: 250 seconds]
11:01 -!- digi_james [sid281632@gateway/web/irccloud.com/x-denjnhnlzrimsgue] has joined #secp256k1
11:02 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-ktsezaoqlasvycih] has joined #secp256k1
11:08 < roconnor> https://github.com/bitcoin-core/secp256k1/blob/1e5d50fa93d71d751b95eec6a80f6732879a0071/src/group_impl.h#L101
11:08 < roconnor> secp256k1_ge_set_gej_var doesn't use _set_infinity.
11:20 < sipa> roconnor: oh interesting, so it doesn't guarantee r is fully initialized after the call
11:22 < gmaxwell> Well until recently that was the norm.  Just looks like something to fix.
11:26 < sipa> yeah, i know, we recently changed that, but it seems this one was missed
11:28 < gmaxwell> the infinity=infinity pattern looks line something to audit for.
11:41 < roconnor> I'll see about making a PR then.
11:45 < roconnor> sipa: IIRC there are some places where these structures get copied, and then we end up with the situation where someone calls ge_set_gej_var and think they've initialized the structure, and then they copy the structure, and then it is unclear if copying undefined values is undefined behaviour.
11:50 < real_or_random> roconnor sipa gmaxwell: see https://github.com/bitcoin-core/secp256k1/issues/776 where we discussed solutions (but apparently noone openend a PR so far)
11:52 < gmaxwell> I think thats unrelated to what roconnor was talking about. :P
11:53 < real_or_random> ah no right, sorry, I was looking for another issue but I can't find it
11:53 < gmaxwell> clang emits memcopy(obja,obja,len) for struct assignments.  It's unambigiously undefined behavior for user code to do that, but the compiler can do whatever. ... except that clang doesn't write or version control libc, so they're actually playing with fire.  But it seems like they don't give a darn because on OSX they do control the libc.
11:54 < gmaxwell> regardless of how dumb clang is being, valgrind can't tell the difference between library and compiler produced memcpy calls.
11:54 < real_or_random> ah ok I wanted to link this thing here https://github.com/bitcoin-core/secp256k1/pull/699#issuecomment-569413087
11:55 < gmaxwell> ah, yeah I vaguely remembed that comment which is why I didn't reply to roconnor with "there is nothing wrong with copying uninitilzied memory". :P
11:56 < real_or_random> lol ok :P
12:04 < roconnor> https://github.com/bitcoin-core/secp256k1/pull/937
12:24 < gmaxwell> real_or_random: "because #925 was merged during CI was running" ? 925 hasn't been merged, you're commenting on 925.
12:24 < real_or_random> pff
12:26 < real_or_random> fixed. that happens when you process github notification during a call
12:30 < roconnor> et tu, secp256k1_gej_double_var?
12:45 < real_or_random> roconnor: https://i.imgflip.com/589fdw.jpg
12:48 < roconnor> that is totally me.
12:49 < roconnor> I'm planning to push to the existing PR, unless it gets merged before I do.
12:51 < gmaxwell> makes sense to me.
12:51 < gmaxwell> did you grep for any others?
12:51 < gmaxwell> (look for assignments to infinity)
12:52 < roconnor> I did grep through infinity.*[01] in that file.
12:52 < roconnor> I wasn't particularly careful in that review, but a cursary glance suggested everything else seemed reasonable.
12:54 < gmaxwell> git grep -E 'infinity ?='
12:54 < gmaxwell> there is a bunch of hits there, but I assume most are fine.
12:56 < roconnor> hmm secp256k1_ge_set_all_gej_var might be problematic.  I'm not so familiar with that function.
13:13 < roconnor> secp256k1_ge_set_all_gej_var even fails to set the infinity flags when all the inputs are infinity.  ... it has issues.
13:18 < sipa> it's only ever used with known non-zero multiples of the generator
13:19 < sipa> (and only during context building, which is typically done at compile time)
13:19 < sipa> doesn't mean that issues shouldn't be fixed of course
13:20 < sipa> if we go for #919 (very unsure), i think it can be removed entirely
13:20 < sipa> ah no, 919 together with making static precomputation mandatory
13:38 < gmaxwell> Yeah, I struggled with that function previously, when I made that PR that makes stuff handle infinities.
13:41 < sipa> i think we could just add a precondition/VERIFY_CHECK to it that none of its inputs are infinity
13:42 < gmaxwell> in theory points could carry a verify flag that indicates if they could be infinity or not.
14:02 < roconnor> Should be fixed in my PR.
17:02 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1
17:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
17:09 -!- belcher_ is now known as belcher
17:22 < gmaxwell> real_or_random: I see #925 has been updated again.  He still hasn't done the part in contrib, it might not have been clear to him that I was asking him to do it, or he might just not understand that change.  I was thinking of ACKing it as is and just doing the other change seperately.
17:22 < gmaxwell> real_or_random: what are your thoughts?
19:55 < gmaxwell> real_or_random: nevermind, he replied!
--- Log closed Wed May 05 00:00:46 2021