--- Day changed Wed Aug 22 2018 01:09 -!- stevoo9 [~stevoo@cpc139594-dund15-2-0-cust230.16-4.cable.virginm.net] has joined #secp256k1 01:11 -!- rosseaux2 [~rosseaux@14.37.105.154] has joined #secp256k1 01:11 -!- stevoo9 [~stevoo@cpc139594-dund15-2-0-cust230.16-4.cable.virginm.net] has quit [Remote host closed the connection] 01:12 -!- rosseaux2 [~rosseaux@14.37.105.154] has quit [Killed (Sigyn (Spam is off topic on freenode.))] 02:51 -!- deusexbeer [~deusexbee@079-170-138-002-dynamic-pool-adsl.wbt.ru] has joined #secp256k1 03:11 -!- Cronus18 [~Cronus@p6e436842.iwatnt01.ap.so-net.ne.jp] has joined #secp256k1 03:13 -!- Cronus18 [~Cronus@p6e436842.iwatnt01.ap.so-net.ne.jp] has quit [Remote host closed the connection] 04:24 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 08:22 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 08:22 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 08:23 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 08:27 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 08:58 < andytoshi> gmaxwell: i spent a bunch of time on the plane yesterday trying to do this .. i was able to get it down to linear memory with a better constant (1 instead of 2) but i think log is impossible 08:58 < andytoshi> you need all the pairwise products, all the 4-way products, etc., up to the product of everything, and i can't find a way to require these in an efficient order 08:59 < andytoshi> i shouldnt' say "i think it's impossible", just that it's much harder than i expected and i don't see how to do it 09:59 -!- TheoM [~TheoM@h83-209-4-21.cust.se.alltele.net] has joined #secp256k1 10:08 -!- TheoM [~TheoM@h83-209-4-21.cust.se.alltele.net] has quit [Ping timeout: 252 seconds] 12:00 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #secp256k1 12:19 -!- adamg [~adamg@199.116.115.145] has joined #secp256k1 12:24 -!- adamg [~adamg@199.116.115.145] has quit [Remote host closed the connection] 13:01 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1 13:01 < BlueMatt> yoyoyo andytoshi 13:01 < BlueMatt> hmmmm...how do I impl this without combine: https://github.com/rust-bitcoin/rust-lightning/blob/master/src/ln/chan_utils.rs#L114 13:01 < BlueMatt> we may need to move this question to upstream #secp256k1 13:01 < andytoshi> hi BlueMatt . can you describe on a high level what these two points are 13:02 < BlueMatt> dont kill mah combine 13:02 < andytoshi> who determines the corresponding secret keys? always the same person? 13:02 < andytoshi> it looks like for channel participants this can be done using ec_pubkey_tweak_add but monitors only see public points 13:03 < BlueMatt> ummm, sec lemme see whats up 13:04 < andytoshi> basically, in general it worries me to see public keys being added without any derandomization .. e.g. what if the per-commitment-point is chosen maliciously to cancel out the revocation basepoint? 13:04 < andytoshi> lemme also try to find the corresponding code in clightning whith uses libsecp256k1 directly 13:05 < BlueMatt> hmm? they're both being multiplied by the result of a sh256 operation first? 13:05 < BlueMatt> before the addition 13:05 < andytoshi> oh derp yep i see 13:05 <@gmaxwell> a sha256 operation on what? 13:05 <@gmaxwell> what goes into the hash? 13:06 < BlueMatt> specifically, both keys are being multiplied by the hash of something that contains themselves 13:06 <@gmaxwell> that contains both keys? 13:06 < andytoshi> gmaxwell: there are always exactly 2 of them, so this is actually ok 13:06 <@gmaxwell> or just each key? 13:06 < andytoshi> but it's just each key 13:06 < BlueMatt> just each key (plus other data) 13:06 <@gmaxwell> yes, so your construction is insecure but for the fact that you never have more than two keys. 13:07 < BlueMatt> oh, no, both keys, just in different order 13:07 < BlueMatt> derp, I cant read 13:07 <@gmaxwell> this would be better done with a pubkey combiner that takes a derandomizer function pointer and defaults to musig. :P 13:07 < andytoshi> ok, `derive_revocation_key` in clightning also does exactly this (using secp256k1_pubkey_combine) 13:08 < andytoshi> is this a standard Lightning thing that would be very involved to change? 13:08 <@gmaxwell> see this is what we get when we screw up and leave interfaces around. 13:08 < andytoshi> if so, i guess we'll have to make the musig randomizer more general before removing pubkey_combine.. 13:08 < BlueMatt> I think technically I can avoid it since always have a private key for one side, but plumbing that through to the channelmonitor sucks ass 13:08 <@gmaxwell> they grow mold 13:10 < BlueMatt> I mean this construction is A*H(A||B) + B*H(B||A) 13:10 < andytoshi> gmaxwell: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#revocationpubkey-derivation 13:12 < andytoshi> looks like it's been around in BOLT 3 since 2016 or so .. and i suspect it's something one of us recommended 13:14 <@gmaxwell> the AB BA thing is fine. just awkward. in any case, if we had a combiner function that took a function parameter for its derandomizer that would be okay. 13:14 < BlueMatt> well that construction's gotta be supported somehow... 13:14 <@gmaxwell> "The I'th secret P: 13:14 <@gmaxwell> MUST match the output of this algorithm: 13:14 <@gmaxwell> " 13:14 <@gmaxwell> 0_o 13:15 < BlueMatt> yea, thats some hairbrained thing tadge came up with that lets you monitor a channel with very limited state 13:15 < BlueMatt> ...except not cause of other complication :/ 13:15 < BlueMatt> otherwise it'd be marginally clever 13:16 <@gmaxwell> it's really convolited way of saying that the I's secret is SHA256(seed ^ I<<208). 13:17 <@gmaxwell> oh no it isn't. 13:17 <@gmaxwell> I see it's a tree. 13:17 < BlueMatt> nono, its intended so that you can store all possible secrets in log(N) space, do effecient derivation (log(N)) and also reveal one at a time 13:17 < BlueMatt> yea 13:30 -!- Numline15 [~Numline1@199.116.115.137] has joined #secp256k1 13:33 -!- Numline15 [~Numline1@199.116.115.137] has quit [Killed (Unit193 (Spam is not permitted on freenode.))] 15:04 < roasbeef> BlueMatt: tadge came up with elkrem, which is waaay simpler, this is shachain which rusty came up with, and we ended using because...reasons (which are very dumb) 15:25 -!- Guest27000 [~OpenSorce@31.204.186.82] has joined #secp256k1 15:27 -!- Guest27000 [~OpenSorce@31.204.186.82] has quit [Remote host closed the connection] 15:29 < BlueMatt> ah, right, yea 16:20 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds] 16:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 19:22 -!- Lightsword_ [~Lightswor@2604:a880:1:20::1d3:9001] has joined #secp256k1 19:28 -!- jonasschnelli_ [~jonasschn@2a01:4f8:172:10da::2] has joined #secp256k1 19:29 -!- Lightsword_ is now known as Lightsword 21:18 -!- MeiR [~MeiR@35.red-88-17-223.dynamicip.rima-tde.net] has joined #secp256k1 21:25 -!- MeiR [~MeiR@35.red-88-17-223.dynamicip.rima-tde.net] has quit [Ping timeout: 256 seconds] 21:30 -!- PuppyKun0 [~PuppyKun@14.51.82.66] has joined #secp256k1 21:37 -!- PuppyKun0 [~PuppyKun@14.51.82.66] has quit [Ping timeout: 272 seconds] 23:51 -!- jonasschnelli_ [~jonasschn@2a01:4f8:172:10da::2] has quit [Changing host] 23:51 -!- jonasschnelli_ [~jonasschn@unaffiliated/jonasschnelli] has joined #secp256k1 23:52 -!- jonasschnelli_ is now known as jonasschnelli