--- Day changed Tue Sep 29 2015
00:31 <@sipa> andytoshi: cool
00:33 <@sipa> gmaxwell: i was about to say that that is inherent... if you can split a pre-existing secret, you can always use your own key as the preexisting one, and 'split off' the other participants' keys, to result in a key you can report
00:34 <@sipa> gmaxwell: that's not correct however, using X+H(X)*G also does not allow splitting a pre-existing secret
02:50 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 240 seconds]
02:52 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1
07:42 -!- nullbyte [~NSA@193.138.219.233] has joined #secp256k1
08:30 < Apocalyptic> andytoshi, fair enough, I see what you meant now
08:33 < Apocalyptic> I think my argument holds for a much weaker statement that "H' is an RO" which we may have, i.e. the irreversibility property of H'
09:19 < andytoshi> Apocalyptic: i've made this mistake before, saying things like "H is a RO, so H^2 must also be" for example and i've argued insecure systems correct with it. took me a while to figure out where my reasoning went wrong
09:20 < andytoshi> and yup
09:48 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds]
10:48 -!- ludbb [~user@gateway/vpn/privateinternetaccess/ludbb] has joined #secp256k1
10:52 < ludbb> hmm.. why did you change the lib so it no longer exports the nonce functions? their symbols are no longer visible, so you can't use them in a wrapper
10:53 -!- nullbyte [~NSA@193.138.219.233] has quit [Quit: leaving]
10:55 < ludbb> on HEAD~20:  nm -g .libs/libsecp256k1.0.dylib | grep nonce
10:55 < ludbb> 00000000000230a0 S _secp256k1_nonce_function_default
10:56 < ludbb> 0000000000023098 S _secp256k1_nonce_function_rfc6979
10:56 < ludbb> on master that is empty
11:02 < ludbb> nevermind about HEAD~20, HEAD~1 is the issue due to commit 118cd82
11:37 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 260 seconds]
11:37 -!- roasbeef_ [~root@104.131.26.124] has joined #secp256k1
11:40 -!- ludbb [~user@gateway/vpn/privateinternetaccess/ludbb] has quit [Ping timeout: 268 seconds]
11:43 -!- ludbb [~user@181.197.20.23] has joined #secp256k1
11:44 <@sipa> ludbb: ah, good point; those are probably not marked as API
11:49 <@gmaxwell> Nope they're not. :) Easy to fix.
11:56 -!- ludbb_ [~user@gateway/vpn/privateinternetaccess/ludbb] has joined #secp256k1
11:58 <@gmaxwell> ludbb_: https://github.com/bitcoin/secp256k1/pull/325
11:58 -!- ludbb [~user@181.197.20.23] has quit [Ping timeout: 240 seconds]
12:14 <@gmaxwell> sipa: so I think the multiparty support will need to support two ways of doing pubkey combining. :( ... linearity busting and no-linearity busting.  Because otherwise the threshold generation stuff cannot work and splitting existing keys cannot work.
12:15 <@sipa> what is the use case for that?
12:16 <@gmaxwell> sipa: For splitting an existing key?   You have some high value (reused :( ) key already in use in a non-multisig way.  And you realize this is a bad idea and want to boost your online security by making it 2 of 2.
12:17 <@gmaxwell> Example would be something like the green address 2 of 2 master key.  Also, as an aside, for your linearity busting... you should also support bip32 on linearity busted keys.
12:18 -!- roasbeef_ is now known as roasbeef
12:19 <@sipa> i don't understand the bip32 part
12:19 <@gmaxwell> For the threshold thing..  You can do a  O(1) size  N of M threshold, if you use an interactive protocol to establish the keys (this is that thing boneh described to us).  Andytoshi apparently had something of an implementation of it.  In any case, I think (but am not totally sure) that its also incompatible with an API that forces linearity busting.
12:20 <@sipa> yeah i think it is incompatible
12:20 <@gmaxwell> sipa: You and I sould be able to establish a 2 of 2 master pubkey, and then people should be able to BIP32 derrive off it.  If you make the API force linearity busting then this will be broken, unless there is some special affordance for adding in an extra pubkey that doesn't have linearity protection.
12:22 <@gmaxwell> hm. actually I might be wrong about the boneh scheme.  Effectively what you do there is create an M of M key (which can have linearity proteciton). Then make shares of your private keys.
12:25 <@sipa> for bip32... i understand the use case, but it is very unflexible
12:26 <@sipa> if you want anything more than a M-of-M, you do need to multisign-combine different revealed chains, rather than turn it into a single chain
12:28 <@gmaxwell> sipa: that isn't the case for the boneh scheme, I think.
12:28 <@gmaxwell> effectively the BIP32 becomes an additional signer.
12:29 <@sipa> you're confusing me by talking about the bip32 and boneh schemes simultaneously
12:29 <@sipa> are they related?
12:29 <@gmaxwell> Boneh scheme is BIP32 compatible. Otherwise unrelated.
12:32 <@gmaxwell> In the boneh scheme 2 of A,B,C   computes  a pubkey which equals A+B+C  where the signers have collaborated to secret share their private keys.      BIP32 public is   P + H(P||chaincode||index)G.    and when P is A + B + C,  it just adds an additional key as required, or alternatively someone signs with +H(..) added to their secret.
12:40 <@sipa> can the boneh scheme work with the linearity break?
12:40 <@sipa> where the signers need to communicate to establish the original a,b,c, and not just their sum?
13:35 <@gmaxwell> on using SIMD 32,32->64 instead of 64,64->128 on sandy bridge, w/ 25519, 20% speedup reported https://eprint.iacr.org/2015/943 (from curves list)
13:52 -!- adam3us [~Adium@89-96-48-178.ip10.fastwebnet.it] has joined #secp256k1
14:10 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1
14:31 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
14:36 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
14:36 -!- arubi [~ese168@unaffiliated/arubi] has joined #secp256k1
14:51 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1
15:28 -!- adam3us [~Adium@89-96-48-178.ip10.fastwebnet.it] has quit [Quit: Leaving.]
15:30 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
17:31 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1
18:47 <@gmaxwell> sipa: wrt unused code--- I'm happy to go cut that back, I have one question--  secp256k1_ge_set_all_gej_var and secp256k1_gej_add_var are !USE_ECMULT_STATIC_PRECOMPUTATION only.  Do I either (a) make them conditional on !staticprecomp or (b) only test -Wunused-functions if compiled without static precomp?
18:48 <@sipa> the interesting thing to me is not having actually-really-totally unused code around
18:52 <@gmaxwell> I would suggest moving those functions into the precomp except we support non-static precomp. :)
18:52 <@gmaxwell> okay, I can do the second thing, though I fear we'll not notice really totally unused code if it's only tested in that weird config.
18:53 <@gmaxwell> (I think if I had to pick a config option to get rid of, that would be my obvious first choice :)...)
18:54 <@sipa> well either is fine...
18:55 <@sipa> actually, no
18:55 <@sipa> i think that code to the extent possible should be defined in a relevant module
18:56 <@sipa> i think that the flexibility we get from having all code in one module is exactly that unused parts don't hurt
18:57 <@sipa> wouldn't it be better to work on automatic code coverage analysis to find unused cod
18:57 <@sipa> ?
19:59 <@gmaxwell> We have that. But not just that, the _compiler_ has that, and its reasonably precise.
20:00 <@gmaxwell> It just doesn't know about all our different build configurations.
20:36 -!- ludbb_ [~user@gateway/vpn/privateinternetaccess/ludbb] has quit [Ping timeout: 264 seconds]
21:36 <@gmaxwell> sipa: okay I reworked PR323, perhaps more to your liking now.
21:43 <@gmaxwell> sipa: you and andytoshi and all your features, we're down to 17.5% of the codebase being tests.  8 months ago we were 22% tests. :P
22:45 -!- adam3us [~Adium@89-96-48-178.ip10.fastwebnet.it] has joined #secp256k1
23:07 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1
23:12 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit]
23:32 -!- adam3us [~Adium@89-96-48-178.ip10.fastwebnet.it] has quit [Quit: Leaving.]