--- Day changed Wed Dec 28 2016 02:52 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 04:17 < gmaxwell> andytoshi: what would you like me to work on in libsecp256k1? 09:02 -!- echonaut2 [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 09:04 -!- echonaut [~echonaut@46.101.192.134] has joined #secp256k1 09:07 < andytoshi> gmaxwell: full test coverage for the malloc and abort stuff 09:08 < andytoshi> assembling a list of all the things we did so that we can outline a libsecp paper 09:08 < andytoshi> then the aggregation stuff, but i guess that's all sipa 09:09 < andytoshi> is there anything i should be working on here? 09:10 < sipa> just attended the valueshuffle talk at 33c3 09:10 < sipa> which is coinshuffle using a mixing network, on top of CT 09:11 < sipa> pretty cool 09:32 < sipa> i pointed out that their protocol requires updating a range proof to a different blinding factor, which we don't know how to do (i think?) 09:32 < sipa> but it can be solved by having an excess value like MW 10:15 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 11:01 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 11:01 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 14:24 < gmaxwell> wht does it need an excess value? why not agree on the sum of the blinding factors first then someone just diminishes their factor by the sum? 14:26 < sipa> if someone diminishes their factor (and adapts their range proof accordingly), the other participants can see which output was changed, and thus deanonimise the participant who does so 14:29 < gmaxwell> sipa: we all show up. no one has published any range proofs, inputs or outputs.. just the N of us. We then each pick a random number, agree on the sum, then person 0 changes his blining factor by the sum... then the protocol begins. 14:31 < sipa> i guess that could allow a small search over all possible amount values to find which commitments belong to which randomizer 14:39 < gmaxwell> you don't learn which randomizer, you only learn the sum. 14:50 < sipa> well if everyone colludes against the participant who updates, they learn that participant's effective blinding factor 14:55 < gmaxwell> if everyone colludes you have no privacy from a CJ anyways. 14:55 < gmaxwell> "Which outputs weren't ours?" 14:56 < sipa> right. 15:02 < gmaxwell> I just don't understand where this constraint comes from, we specifically setup the api in elements alpha so that you can make your blinding factors sum to an arbritary constant, specifically so a coinjoin process could come up with constants to use and just give them to you. 15:37 < sipa> i'm aware, but at the time i didn't know of a way to join such that even the participants do not learn which outputs belong to which participant 15:37 < sipa> so that adds extra requirements 15:40 < gmaxwell> There are well known protocols for that, it's the same protocols you need for coming up with secret shares in a distributed manner. 15:41 < gmaxwell> e.g. you take the blinding factor you want to use, split it into N-1 parts, give them to the N-1 peers. everyone sums what they got, now share those sums, an you learn the collective sum. or something like that. 15:43 < sipa> that means you now have a bunch of blinding factors with a known summ 15:43 < sipa> you still a way for people to agree on the actual outputs without correlating them 15:43 < sipa> *need 15:44 < sipa> but yes, if you do that with a mixing network, i agree 15:44 < gmaxwell> yes, but thats the same problem as the prior private protocols for coinjoin address. 15:44 < sipa> sure 15:44 < sipa> i wasn't aware there were any at that time :) 15:45 < gmaxwell> (I suggested a simple one in the coinjoin thread, in fact. Though traitor tracing was a pain for it.) 19:28 -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 265 seconds] 19:35 -!- adlai [~adlai@unaffiliated/adlai] has joined #secp256k1