--- Log opened Wed Jan 12 00:00:28 2022 01:51 -!- sgiath [~sgiath@2a02:25b0:aaaa:aaaa:a3c3:ed4b:6b06:0] has joined #secp256k1 02:41 -!- jesseposner [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds] 03:33 -!- jesseposner [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has joined #secp256k1 03:54 -!- stickies-v_ [~stickies-@host-92-8-99-192.as13285.net] has joined #secp256k1 03:55 -!- stickies-v [~stickies-@81.178.227.161] has quit [Ping timeout: 240 seconds] 04:12 -!- stickies-v_ [~stickies-@host-92-8-99-192.as13285.net] has quit [Ping timeout: 256 seconds] 04:14 -!- stickies-v [~stickies-@host-92-8-97-28.as13285.net] has joined #secp256k1 05:13 -!- stickies-v [~stickies-@host-92-8-97-28.as13285.net] has quit [Ping timeout: 256 seconds] 05:14 -!- stickies-v [~stickies-@host-92-8-97-28.as13285.net] has joined #secp256k1 08:59 -!- jesseposner [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 09:49 < mercurian> hey andytoshi; I'm taking another look at your uncompressed bulletproofs work on -zkp, and I'm wanted to just double-check my understanding of the size of the proofs created; am I right that a proof's size will always be less than 194 + n_bits * 64? 09:52 < andytoshi> mercurian: that sounds right, but i definitely don't know that number offhand these days :) 09:52 < andytoshi> but yes, two scalars per bit plus 7 or so initial things (i think 5 scalars and 2 points? but i don't remember) 09:52 < andytoshi> maybe it was 9 initial things 10:14 < mercurian> hehe 10:15 < mercurian> andytoshi: would it make sense to make a convenience function-like macro that returns the size of a proof given n-bits? 10:16 < andytoshi> mercurian: yeah i think so, we have analogous things for our other crypto proofs 10:17 < mercurian> andytoshi: mind pointing out an example? / would the right way for me to contribute such a thing be to PR against your branch? 10:18 < mercurian> (and, implicitly in the above, would you be open to such a contribution?) 10:20 < andytoshi> mercurian: sure, a PR against my branch would be great 10:20 < andytoshi> and yep one sec.. 10:20 < andytoshi> mercurian: well, or you can just make a branch and link it here, i can cherry-pick your commets 10:21 < andytoshi> mercurian: https://github.com/ElementsProject/secp256k1-zkp/blob/master/include/secp256k1_surjectionproof.h#L130-L139 hmm, so this actually assumes you have a proof object and gives you a length from there 10:21 < andytoshi> i think a reasonable API for uncompressed bulletproofs would be to just take n_bits and output a size_t 10:22 < mercurian> I'm generally of the opinion that you should only require arguments which you need; so, assuming n_bits is indeed the only variable which affects the size of the proof-length, I'd whole-heartedly agree 10:24 < mercurian> andytoshi: I'd prefer to do whichever would make less work for you ☺ 10:35 -!- Netsplit *.net <-> *.split quits: jnewbery, johnzwen-, jonasschnelli_, RubenSomsen, cfields, fjahr, glozow, BlueMatt[m], elsirion, harding, (+35 more, use /NETSPLIT to show all of them) 10:39 -!- DeanGuss- [~dean@nonplayercharacter.me] has joined #secp256k1 10:39 -!- Netsplit over, joins: pink_sarco 10:39 -!- orionwl [~laanwj@user/laanwj] has joined #secp256k1 10:39 -!- Netsplit over, joins: RubenSomsen, glozow, fanquake, lightningbot 10:39 -!- yakshaver123 [yakshaver@2600:3c00::f03c:92ff:fe8e:dce6] has joined #secp256k1 10:39 -!- Netsplit over, joins: sgiath, michaelfolkson, kanzure, ajonas, ghost43, fjahr, robertspigler, sipa, siv2r[m], luke-jr (+27 more) 10:40 < mercurian> 👍 10:41 < mercurian> andytoshi: and one final question (which is maybe also a bikeshed): is it worth providing a function-like macro so that the size can be used in array-declarations? / is providing both a function-like macro and a real function worth it? 10:41 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection] 10:43 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined #secp256k1 10:43 < andytoshi> mercurian: oh, neat question 10:43 < andytoshi> actually maybe we should *only* provide the macro 10:44 < andytoshi> since the formula is so simple and will not overflow for any reasonable number of bits (in fact >64 bits is forbidden) 10:44 < mercurian> (that'd be my preference; and offer SECP256K1_BULLETPROOFS_RANGEPROOF_UNCOMPRESSED_MAX_LENGTH_ as just a shortcut through that function-like macro 10:44 < mercurian> ) 10:44 < andytoshi> yep, sounds good 10:45 < mercurian> 👍 10:45 < andytoshi> lol at these massive names, but i think it's ok, the uncompressed rangeproof stuff is kinda niche (or at least, an implementation detail of a real system) 10:46 < mercurian> OneDay™ we can have shorter names ☺ 10:46 < andytoshi> :) 10:51 < mercurian> (who knows, maybe C3x will add true namespacing) 12:04 < andytoshi> hah, i actually suggested this on comp.lang.c once and was told that namespacing was somehow the most complicated thing that anybody ever suggests for C 12:04 < andytoshi> blah blah blah name mangling linker rules etc 12:07 < mercurian> I mean 12:08 < mercurian> one of the things I love about C is that my function names become labels in the object output 12:08 < mercurian> (name-mangling always kills me a bit) 12:08 < mercurian> but I'm less and less sure that such a feature is worth the trade-off of not having reasonable name-spacing 12:09 < mercurian> additionally, I thought I read that C might get lambdas in C2x, and if that's the case then name-mangling is already where C is headed 12:09 < sipa> I think the kind of mangling needed to support namespacing also pales in comparison to what is needed to map arbitrate templated C++ types into linker symbol names... 12:11 < mercurian> mmmmmmtemplates 12:11 < sipa> *arbitrary 12:11 < sipa> but even that doesn't seem to be much of an issue in practice 12:15 < mercurian> let's just mangle names by concatenating the return-type, the identifier, and the type of each parameter, and then sha256 it 12:15 < mercurian> what could go wrong? ☺ 12:15 < sipa> Seems pretty well-defined. By why bother with the SHA256? 12:16 < sipa> Ah, no, not the identifiers; those aren't part of function signatures. 12:16 < mercurian> … what? 12:16 < mercurian> if you exclude the identifier, wouldn't that mean two functions with the same signatures resolve to the same mangled-name? 12:17 < sipa> `int foo(int x)` and `int foo(int y)` are the same function 12:17 < mercurian> the function identifier 12:17 < mercurian> not the parameter names 12:17 < sipa> oh, you mean the identifier of the function itself! right of course 12:17 < mercurian> ☺ 12:18 < mercurian> sipa: also “because sha256 is a good function” isn't a good enough reason? ☺ 12:18 < mercurian> (mostly, I was thinking about uniformity and avoiding object code bloat in the face of huge parameter lists) 12:18 < sipa> it has a downside: you can't ever demangle, which is kind of useful for debugging 12:19 < mercurian> an alternative way of phrasing that is, “if you can figure out how to demangle the names, you win a prize” 12:20 < sipa> what you're describing, ignoring the SHA256, is effectively C++ name mangling 12:20 < mercurian> pretty much 12:20 < sipa> though some encoding is used for types, rather than just their string form 12:20 < mercurian> they need to include template arguments as well (which is why types can't simply be the obvious string name) 12:21 < mercurian> (if I'm remembering correctly; been a while since I read that part of the standard) 12:21 < sipa> Well, no, the string form of a name would include the template arguments. 12:22 < mercurian> sipa: also, debug symbols can just include a rainbow table that you build-up during compilation 12:22 < sipa> `std::set` i mean then, where the name of the template is `std::set`. 12:23 < mercurian> sipa: I think we're saying the same thing 12:23 < sipa> mercurian: That's true, but the symbol names themselves (excluding those exported by libraries) are *also* just debug info. So what does it matter if you store stuff in the symbol table or the ... full-symbol table? 12:23 < sipa> I also suspect you don't mean a rainbow table. Those are used to reduce disk storage for password cracking, and have little use otherwise. 12:24 < mercurian> I suppose I more just mean a hashmap 13:16 < andytoshi> mercurian: ACK your length formula. i found a function of my own which implements it (though i haven't figured out where/if it was committed, i messed up my git repo pretty badly some months ago doing manual surgery on worktrees..) 13:16 < andytoshi> and my formula matches yours 13:16 < mercurian> solid 13:18 < andytoshi> hmm it is in https://github.com/ElementsProject/secp256k1-zkp/pull/123 but i have no idea what that PR is or why it was closed 13:18 < andytoshi> anyway i'll just cherry-pick your version 13:18 < andytoshi> lol, i opened and closed that PR exactly one year ago 13:21 < mercurian> git is incredibly useful, but it also gives you 7x the amount of rope necessary to never be able to be organized 13:21 < mercurian> andytoshi: I feel your pain 13:55 -!- DeanGuss- is now known as DeanGuss 13:55 -!- DeanGuss [~dean@nonplayercharacter.me] has quit [Changing host] 13:55 -!- DeanGuss [~dean@user/deanguss] has joined #secp256k1 14:27 < mercurian> this may seem like a really strange question; is there a facility provided by libsecp (that I'm not seeing) which recovers a blinding factor from a pedersen commitment given the value committed-to? 14:28 < sipa> That requires solving the discrete logarithm. 14:29 < mercurian> oh, strange that that's not provided then /sarcasm 14:29 < mercurian> sipa: thank you! 14:29 < sipa> I mean, it's perfectly doable. Just might not finish before the heat death of the universe. 14:30 < mercurian> I suppose I already mentioned to the folks I'm working with that this implementation might not be as performant as we had hoped 14:30 < mercurian> :) 17:33 -!- stickies-v [~stickies-@host-92-8-97-28.as13285.net] has quit [Ping timeout: 256 seconds] 17:33 -!- stickies-v [~stickies-@81.178.231.129] has joined #secp256k1 21:57 -!- meshcollider [meshcollid@user/meshcollider] has quit [Ping timeout: 256 seconds] 22:00 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined #secp256k1 23:46 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #secp256k1 23:49 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 256 seconds] 23:49 -!- lukedashjr is now known as luke-jr --- Log closed Thu Jan 13 00:00:29 2022