--- Day changed Fri Aug 05 2016
01:39 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #secp256k1
02:30 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds]
03:46 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #secp256k1
03:50 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 250 seconds]
04:03 -!- arubi__ [~ese168@unaffiliated/arubi] has joined #secp256k1
04:07 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
06:48 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #secp256k1
06:51 -!- arubi__ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
07:19 -!- arubi__ [~ese168@unaffiliated/arubi] has joined #secp256k1
07:23 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 244 seconds]
08:06 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #secp256k1
09:11 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1
09:15 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Client Quit]
09:18 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1
09:45 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.]
09:46 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1
10:09 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.]
10:44 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1
11:16 -!- arubi__ is now known as arubi
13:31 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #secp256k1
13:33 < bsm117532> I'm thinking of building a Shamir's Secret Sharing implementation using libsecp256k1's optimized field element routines.
13:33 < bsm117532> Is there any reason this might be a Bad Idea?  i.e. this prime might be inappropriate for this use?
13:37 < gmaxwell> this would be a bad idea.
13:37 < gmaxwell> You can do secret sharing over bytes, it will be much simpler and much faster.
13:37 < bsm117532> Indeed, I've considered that.
13:38 < gmaxwell> using a large field results in a quadratic slowdown, plus overhead since the size of the data you encode usually isn't some multiple of the field size.
13:39 < gmaxwell> also, secret sharing is usually of limited use. It's also been done many times before. e.g. https://github.com/TheBlueMatt/shamirs
13:40 < bsm117532> Yeah I found that one, and I have an interesting new use.  ;-)
13:42 < bsm117532> The reason to use a prime field is in order to do commitments on them so participants can verify that the secret sharing was successful.
13:42 < bsm117532> *commitments on the shares
13:44 < bsm117532> Using Feldman's scheme.  This is why I'm interested in secp256k1.
13:53 < gmaxwell> for many applications there are simpler approaches that don't require a dealer and make verification much simplier.
13:54 < gmaxwell> but you could do what you're describing there.
13:56 < bsm117532> I've read a few papers trying to find the right algorithm, most recently this one: http://www.cs.cmu.edu/~wing/publications/Wong-Wing02b.pdf
13:56 < bsm117532> But I'd be happy to hear suggestions of other literature gmaxwell
13:57 < bsm117532> (I need a verifiable, redistributable scheme, and am not concerned about trusting the dealer)
13:59 < gmaxwell> if you don't mind trusting the dealer, why not just have the dealer keep the secret. Problem solved.
14:00 < bsm117532> The dealer wants to distribute his secret to trustees as a backup for himself losing it.  (Yes I'm talking about bitcoin keys)
14:10 -!- molly [~molly@unaffiliated/molly] has joined #secp256k1
14:12 < gmaxwell> bsm117532: if the dealer is completely trusted where does the verifyability requirement come from?
14:13 < bsm117532> The trustee set may change, and they want to verify re-sharing.
14:13 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
14:14 < gmaxwell> In any case, all interpolation complexity (and the need to generate independay polynomails) can be avoided if the dealer, just generates m choose n  random combinations of n shares which sum to s, then hand out each share of each combination to the relevant party.
14:15 < gmaxwell> The set can't really change without changing keys, of course, since the any N of the prior trustee set, even once removed, can recover the secret.
14:16 < bsm117532> Yes if you require m of n and remove m from the set n, you have to change keys.
14:18 < bsm117532> Your algorithm grows very quickly in m and n, Shamir's polynomial interpolation is more space efficient.
17:02 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.]
18:20 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-uamxzsilsqmqncvu] has quit [Quit: Connection closed for inactivity]
18:27 -!- pigeons [~pigeons@94.242.209.214] has quit [Remote host closed the connection]
18:28 -!- pigeons [~pigeons@94.242.209.214] has joined #secp256k1
18:28 -!- pigeons is now known as Guest21622
18:41 -!- Guest21622 is now known as pigeons
19:31 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 276 seconds]
19:48 -!- pigeons [~pigeons@94.242.209.214] has joined #secp256k1
19:49 -!- pigeons is now known as Guest80390
19:52 -!- Guest80390 is now known as pigeons
20:10 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 240 seconds]
20:11 -!- pigeons [~pigeons@94.242.209.214] has joined #secp256k1
20:11 -!- pigeons is now known as Guest19508
20:12 -!- FNinTak [~jonhbit@dhcp-18-111-10-93.dyn.mit.edu] has joined #secp256k1
20:24 -!- Guest19508 [~pigeons@94.242.209.214] has quit [Ping timeout: 252 seconds]
20:25 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-rmlmrflropeoozsh] has joined #secp256k1
20:29 -!- pigeons [~pigeons@94.242.209.214] has joined #secp256k1
20:29 -!- pigeons is now known as Guest79503
21:00 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds]
21:03 -!- aalex [~aalex@64.187.177.58] has joined #secp256k1
21:09 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded]
21:09 -!- aalex [~aalex@64.187.177.58] has joined #secp256k1
22:05 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]