--- Log opened Mon Oct 22 00:00:44 2018 00:01 -!- klot [~klot@188.113.35.204] has joined #secp256k1 00:02 -!- klot [~klot@188.113.35.204] has quit [Remote host closed the connection] 00:02 -!- klot [~klot@188.113.35.204] has joined #secp256k1 00:03 -!- klot [~klot@188.113.35.204] has quit [Remote host closed the connection] 00:04 -!- klot [~klot@188.113.35.204] has joined #secp256k1 00:05 -!- klot [~klot@188.113.35.204] has quit [Remote host closed the connection] 00:05 -!- klot [~klot@188.113.35.204] has joined #secp256k1 00:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 00:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 01:15 -!- lexyon [uid324840@gateway/web/irccloud.com/x-vxonefbexrbiopln] has joined #secp256k1 01:19 -!- deusexbeer [~deusexbee@080-250-078-027-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 264 seconds] 01:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 01:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 04:35 -!- klot_ [~klot@188.113.48.142] has joined #secp256k1 04:36 -!- klot_ [~klot@188.113.48.142] has quit [Remote host closed the connection] 04:36 -!- klot_ [~klot@188.113.48.142] has joined #secp256k1 04:37 -!- klot_ [~klot@188.113.48.142] has quit [Remote host closed the connection] 04:38 -!- klot_ [~klot@188.113.48.142] has joined #secp256k1 04:38 -!- klot [~klot@188.113.35.204] has quit [Ping timeout: 252 seconds] 04:43 -!- ken2812221_ [~ken281222@110.50.135.178] has joined #secp256k1 05:14 < nsh> seen this? "As part of the implementation of our zero-knowledge contingent service payment protocol, we produced an efficient boolean circuit for SHA-256. The format of our circuit is the same as the one used in the Bristol circuits. The Bristol page does contain a SHA-256 circuit. However, our circuit was optimized to have far fewer AND gates. We share it here as we think it may be useful in general." http://stevengoldfeder.com/projects/circuits/sha2circuit.h 05:14 < nsh> tml 05:14 < nsh> ( http://stevengoldfeder.com/projects/circuits/sha2circuit.html ) 08:14 -!- lexyon [uid324840@gateway/web/irccloud.com/x-vxonefbexrbiopln] has quit [Quit: Connection closed for inactivity] 12:15 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1 12:17 -!- lexyon [uid324840@gateway/web/irccloud.com/x-fjdtzaqubyrqrgyz] has joined #secp256k1 12:18 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds] 12:30 -!- ken2812221_ [~ken281222@110.50.135.178] has quit [Ping timeout: 240 seconds] 12:41 < andytoshi> nickler: so, in our simplified musig workflow, the only function that takes a scratch space is `secp256k1_musig_pubkey_combine` .. i'm considering making this allow a NULL scratch space in which case it falls back to ordinary `secp256k1_ecmult` and summing 12:42 < andytoshi> i wonder if `ecmult_multi` should do this more generally, it's a fairly simple change that would let people make a time/memory tradeoff 12:54 -!- klot_ [~klot@188.113.48.142] has quit [Read error: Connection reset by peer] 12:56 < nickler> andytoshi: yeah that would be nice 15:19 < andytoshi> nickler: https://github.com/apoelstra/secp256k1-mw/blob/2018-10-new-musig/include/secp256k1_musig.h new musig API 15:20 < andytoshi> i still have to fix the scriptless script unit test, but i did all the API tests, which cover the new functionality 15:21 < andytoshi> gmaxwell: can you take a look at the comment block at the top of that file, and tell me your thoughts on how responsible it would be to publish such an API 15:21 < andytoshi> "if you have memory, keep everything there. if you don't, you'll need to serialize everything. we provide no API because this is basically impossible to get right. here's some free advice. good luck." 15:27 < gmaxwell> I dunno if we should have any non-opaque structs exposed... simply because they tie our hands on upgrades. 15:31 < andytoshi> well, we basically can't write a generally useful but non-footgunny API here 15:31 < andytoshi> and if we use opaque structs we have to choose "generally useful" 15:34 < gmaxwell> we could still have a serialize_secp256k1_musig_session_unsafely() function. 15:34 < gmaxwell> just to prevent any change to the struct being an api break? 15:36 < gmaxwell> as an aside we could make it harder to misuse by sticking the address of itself inside it or something so the its more replace robust. 15:36 < andytoshi> well, i think that for certain applications users actually need to mess around with individual fields 15:36 < andytoshi> the current API requires you know the message to sign before any nonce commitments have been passed, it requires you go through the musig protocol ... having a fixed list of nonces (like e.g. what the lightning people are doing) will break that 15:37 < gmaxwell> just speaking from expirence, I've always eventually regretted having a non-opaque struct anywhere in a library interface. 15:37 < andytoshi> in liquid we were planning to sideload nonce commitments in earlier rounds' signing protocol, befare the next round's message is known 15:37 < andytoshi> hmm, ok, i'll think about how to make this opaque 15:37 < sipa> (not having looked at the code) isn't it possible to expose a 2nd more low-level API for manipulation the state objects, rather than exposing the fields? 15:38 < andytoshi> i could just add getters/setters for the specific fields i think people have to screw with 15:38 < andytoshi> sipa: yeah 15:38 < gmaxwell> I think thats a better way to do that, generally. 15:39 < andytoshi> ok, sure, i can do that (and even use those internally, so i can use our usual "giant unsigned char[] blob" method of making structs opaque without killing myself trying to get indices right all over the codebase) 15:39 < andytoshi> and i will tag all of these with `_unsafe()` and advice against their use for the common case 15:40 < gmaxwell> you could also put their declariations in the public api headers behind an ifdef. 15:40 < gmaxwell> #define SECP256K1_JOIN_MUSIG_SUICIDE_PACT 1 15:40 < andytoshi> lol 15:41 < andytoshi> we need the suicide pact on for our own code right? we'd need to somehow have our exported type have the same size as the struct that we export to non-suicidal users 15:41 < sipa> you can have opaque objects that are allocated by the API, so you don't need to expose their size 15:42 < andytoshi> yes, that's what i do in all my non-secp C code 15:42 < sipa> that's annoying on platforms where you want to avoid allocation though 15:42 < andytoshi> yes 15:43 < gmaxwell> generally it's better to make their size hidden too... if our size is going to be visible for this one we should probably add a couple dummy fields, so we could implement a size increasing fix without breaking ABI. 15:43 < andytoshi> unfortunately you need to publish the size to make these stack-allocable 15:44 < andytoshi> sure i can add dummy fields 15:50 < gmaxwell> how big is this struct? 15:50 < andytoshi> on my system it's 332 bytes 15:51 < gmaxwell> guess we don't want to assume users have access to alloca. :P 15:51 < gmaxwell> okay, no so big that we wouldn't want to stack allocate it. 15:51 < andytoshi> right 15:51 < andytoshi> :P i had the same thought about alloca 15:51 < andytoshi> i've never used alloca, i learned C from "if it's not in C89 it doesn't exist" comp.lang.c 16:05 < sipa> it's a hack to avoid the need for allocating arrays of dynamic size on the stack :) 16:10 -!- lexyon [uid324840@gateway/web/irccloud.com/x-fjdtzaqubyrqrgyz] has quit [Quit: Connection closed for inactivity] 17:51 -!- ken2812221 [~ken281222@110.50.135.178] has joined #secp256k1 19:33 -!- ken2812221 [~ken281222@110.50.135.178] has quit [Ping timeout: 272 seconds] --- Log closed Tue Oct 23 00:00:45 2018