--- Day changed Sun Nov 13 2016 04:38 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-avdaurmuneuquceh] has quit [Quit: Connection closed for inactivity] 05:20 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-qmtvrbnqcjimtdpx] has joined #secp256k1 07:31 -!- aalex [~aalex@64.187.177.58] has joined #secp256k1 08:05 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds] 11:04 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #secp256k1 14:39 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds] 14:46 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-qmtvrbnqcjimtdpx] has quit [] 14:47 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-biyjonupookvcyfh] has joined #secp256k1 15:23 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #secp256k1 18:58 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-biyjonupookvcyfh] has quit [Quit: Connection closed for inactivity] 19:33 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 19:41 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Ping timeout: 260 seconds] 19:42 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #secp256k1 21:07 -!- aalex [~aalex@64.187.177.58] has joined #secp256k1 21:43 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 258 seconds] 22:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #secp256k1 22:01 < rusty> So, if I have keypairs (secret1,pub1) and you have (secret2,pub2), how would I combine them into one key st. we both know the resulting pubkey, and I can hand you secret1 and you'll have the secret key? Seems like I want secp256k1_ec_pubkey_tweak_add(), except with a pubkey not a uchar tweak[32]. 22:09 < sipa> are you worried about pubkey cancellation? 22:11 < sipa> (i come up with a pubkey such that the sum of our keys is something only i know the private key of) 22:12 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-chjkrthevmuprlzz] has joined #secp256k1 22:13 < rusty> sipa: no, since I *want* you to know the secret key, and not me. 22:15 < rusty> This is for lightning's revocation keys. The idea is that A and B create a script together paying to , and after secret exchange, in the end only B knows the . 22:15 < roasbeef> sipa, he's asking how to perform pub2*secret1 using y'alls API 22:16 < roasbeef> or G*secret1 + pub2 22:16 < roasbeef> iirc there's some double scalar mult function 22:19 < rusty> roasbeef: yeah, I'm trying to make sure I understand tadge's proposal. 22:20 < sipa> oh, you mean the pay-to-contract construction? 22:20 < sipa> i have pubkey Q 22:20 < roasbeef> yeh 22:20 < sipa> you come up with a blinding factor k, and compute Q' = Q + H(Q || k)*G 22:20 < sipa> once i hand you k, you know how to spend from it 22:21 < roasbeef> I don't think we need the hashing step for our use-case, as if they aren't able to sign with that pubkey, then they'll never be able to claim a revocation output if it comes down to it 22:24 < gmaxwell> roasbeef: without a hash a p2contract is not generally binding. e.g. I could compute two contracts, X and Y and then have an output which looks like one or the other depending on which I want to call my base pubkey. 22:25 < rusty> roasbeef: so you're saying Q' = Q+ k*G? A hands B k*G, and knowing the (persistent, reusable) base point Q, both sides know Q'. Hmm... 22:26 < roasbeef> rusty: iirc, tadges deviation from we had originally, is that Alice now sends two points instead of a single revocation pubkey. The two points are derived from turning a shachain element into two points (timeout and revocaiton) 22:28 < rusty> roasbeef: yeah, using HMAC(node, "R") and HMAC(node, "T"). So he multiplies these by G and sends them to counterparty? 22:31 < rusty> I think that's where I got lost. Seems like using a simple blinding factor would work, though we're back to "how do I add Q + in libsecp" I think. 22:31 < roasbeef> gmaxwell: yeh that's the case for p2ch proper, but I don't think that matters for our use case as your pubkey is fixed from the time we create the channel 22:32 < roasbeef> rusty: so Alice sends hmac(node, R)*G + bobKey and hmac(node, T)*G + aliceKey 22:32 < roasbeef> before alice's timeout key didn't change with each state, but now it's randomized with each update 22:33 < rusty> roasbeef: ah, so getting Alice to add the keys does solve the API problem, I guess. 22:34 < rusty> roasbeef: I assume the separate hmac values are needed because otherwise Bob could derive them somehow? 22:34 < rusty> Damn, GTG,will read logs for clues so please continue :) 22:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #secp256k1 [] 22:36 < roasbeef> the hmac values aren't meant to obscure things from bob's view, it's to make channels watched by the outsourcable indistinguishable 22:36 < roasbeef> reviewing tadge's slides from Milan might help, though I guess we'll all be talking in a few hours so we should be able to clear things up pretty quickly :) 22:47 < roasbeef> rusty: I think you want secp256k1_gej_add_ge_var 22:48 < roasbeef> as alice when you calculate your timeout pubkey, you can use secp256k1_ecmult (does double scalar mult: a*G + b*G)