--- Day changed Fri Sep 25 2015 00:17 -!- Guest16568 is now known as maaku 02:10 -!- adam3us [~Adium@smb-adpcdg1-02.hotspot.hub-one.net] has joined #secp256k1 02:52 -!- adam3us [~Adium@smb-adpcdg1-02.hotspot.hub-one.net] has quit [Quit: Leaving.] 03:48 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 246 seconds] 04:10 -!- jtimon [~quassel@160.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 06:43 < wumpus> holy crap. debian installer is kind of offensive. It needlessly hard binds language/country/timezone... you pick a language and it limits what countries you can select, pick a country and it limits what timezones you can select. <- yes... :/ 06:54 -!- Pierre_Rochard [~Pierre@unaffiliated/pierre-rochard/x-3593157] has joined #secp256k1 07:57 <@sipa> wumpus, gmaxwell: i probably never noticed, but i'm sure that when selecting central european time, i could still select english 08:00 < wumpus> you can, but you ma have to go though an extra dance to do so. I don't exactly remember, but I do remember having the problem (and had to go back in the installer) at some point 08:02 < wumpus> nah, next time I'll just select Icelandic :-) 08:02 -!- Pierre_Rochard [~Pierre@unaffiliated/pierre-rochard/x-3593157] has quit [Quit: Pierre_Rochard] 08:21 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 250 seconds] 08:36 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #secp256k1 08:49 <@gmaxwell> sipa: perhaps we should move the things in secp256k1.h that users shouldn't be reading to another header file? 08:49 <@gmaxwell> (And I guess I need to add some documentation related to those macros too...) 08:51 <@sipa> meh 08:52 <@sipa> i think only some users read macro definitions anyway 08:52 <@gmaxwell> I mean the header would be included by secp256k1.h, of course. Just trying to cut down on the rate of callers being directed to read that header (where the docs are) and thinking they need to use or mess with those macros. 08:53 <@sipa> i think very few people have the urge to mess with the. 08:53 <@sipa> and it's short enough 08:53 <@sipa> and quite typical 08:54 <@gmaxwell> What is the origin of your dislike for moving them? Seems costless to me, and then secp256k1.h would be 100% things the caller needs to know about. 08:55 <@gmaxwell> (to be clear I'd only move PREREQ/NONNULL/API macros. 08:55 <@gmaxwell> ) 08:57 <@sipa> if we add more files, i think we should move them to a subdirectory etc 08:57 <@sipa> secp256k1/secp256k1.h secp256k1/schnorr.h etx 08:57 <@gmaxwell> Ah okay. 08:57 <@sipa> maybe we should do that anyway 08:58 <@gmaxwell> It's API breaking to do so... so if we think we might want to later... 08:58 < maaku> gmaxwell: my intuition would be to more clearly break up (with comment blocks) the various sections in a single file 08:58 < maaku> guide the user through the file 08:59 <@sipa> maaku: also fine by me 08:59 < maaku> but I don't care much, and sipa's suggestion would be cleaner if someday you want secp256k1 to be more modular 09:00 <@sipa> we already have 3 optional modules! 09:26 <@gmaxwell> maaku: yea it's just a little sad I think to have a /* No user serviceable parts inside this section. */ basically at the top of a file that is otherwise 100% /* Users really should read this. */. 10:01 -!- adam3us [~Adium@host-92-18-104-29.as13285.net] has joined #secp256k1 10:42 -!- adam3us [~Adium@host-92-18-104-29.as13285.net] has quit [Quit: Leaving.] 11:20 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 11:20 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit] 11:46 -!- adam3us [~Adium@host-92-18-104-29.as13285.net] has joined #secp256k1 12:09 -!- adam3us [~Adium@host-92-18-104-29.as13285.net] has quit [Quit: Leaving.] 12:22 -!- jtimon [~quassel@160.28.134.37.dynamic.jazztel.es] has joined #secp256k1 13:51 -!- jtimon [~quassel@160.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 272 seconds] 14:27 -!- jtimon [~quassel@160.28.134.37.dynamic.jazztel.es] has joined #secp256k1 14:55 <@sipa> hmm, i don't know whether signing the public nonce with your private key prevents any interesting attack 14:56 <@sipa> if 3 people want to get 3-of-3 multisig, the third can just claim "my public key is X-A-B", where X is his real public key, and A and B are person 1 and 2's public keys 14:57 <@sipa> so the result public key will be X, and the 3rd can just construct a valid 3-of-3 signature without any interaction 14:58 <@sipa> so you really need to do this "is X able to actually sign on his own" verification before deciding to create the "address" 14:59 <@sipa> afterwards it is already too late 14:59 <@sipa> gmaxwell, andytoshi: comments? 15:02 <@sipa> where can you even do that verification? it would mean that senders to the multisig need to communicate with all 3 receivers beforehand 15:02 <@sipa> which sort of defeats the composability feature 15:11 <@sipa> that's of course the same problem as creating a p2sh multisig today with 3 people, and then one of them telling a sending "send here to pay us", while it's just his own address instead of the p2sh one 15:11 <@sipa> you have to assume that whomever you're getting the address from, is the one you are paying 15:12 <@sipa> if you want to be sure you're paying multiple people, you indeed have to verify that they all sign off on the address 15:51 <@sipa> OH! 15:51 <@sipa> but there is another vulnerability 15:53 <@sipa> if i'm the last one to pick a public nonce, i can pick one that causes the joint public nonces to be equal to a previous joint public nonce that was used with one or more of the same signers 15:56 <@sipa> never mind, that doesn't teach you anything 16:11 <@sipa> gmaxwell: bottom line, i'm not sure what the signature is actually needed for 16:12 <@sipa> except being able to detect MitM of the nonces 17:46 <@gmaxwell> sipa: signing with your proported public key shows that you haven't constructed it as a function of the other public keys. 17:47 <@gmaxwell> thus turning the 3 of 3 not into an actual 3 of 3 but instead a 1 of 1. 17:48 <@gmaxwell> as in Alice, Bob, and malory. And M claims her key is M-A-B and then funds are sent to A+B+(M-A-B) and M can sign for them. 17:48 <@gmaxwell> oh I see what you're saying, that signing the nonces doesn't solve that. 17:48 <@sipa> indeed 17:49 <@sipa> the only place where the attack can occur is when someone chooses to pay you using a particular address, and the trust issue is unavoidable there 17:50 <@sipa> well there is the fooling of the cosigners, at address creation time 17:51 <@sipa> A B and C construct a multisig, A and B public their keys, C publishes C-A-B... and then A decides "ok, so the joint address will be (C-A-B)+A+B!" 17:51 <@sipa> and now A happily gives out C as the joint address 17:52 <@sipa> so that is something to prevent by exchanging only signed pubkeys 18:06 <@gmaxwell> brown paper bags for all. :) 18:49 < midnightmagic> Well. Okay, I'm going to clean up my patch then, delete the other random benchmark programs and configure built-in multi-threadedness options. 18:50 < midnightmagic> UNLESS YOU TELL ME NOT TO dun dun dunnnnnn 19:01 <@sipa> gmaxwell: still... no good reason to do it at nonce exchange time 19:01 <@sipa> except to detect mitm of the messages