--- Day changed Mon Feb 05 2018
00:56 -!- nsh- is now known as nsh     
03:39 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Ping timeout: 256 seconds]     
03:40 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #secp256k1     
04:10 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Ping timeout: 240 seconds]     
04:33 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #secp256k1     
04:49 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Ping timeout: 268 seconds]     
04:55 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #secp256k1     
10:22 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1     
10:23 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
11:20 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 255 seconds]     
11:26 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1     
11:27 < maaku> kallewoof: the naive key addition approach requires extra steps to be secure
11:28 < maaku> if Alice and Bob combine keys by literally doing A + B, then Bob could claim his key is B' = B - A, then the combined key is A + B - A = B ; Bob steals the funds
11:31 < maaku> there are various ways to fix this in the setup protocol, such as precommitting to the keys before anyone reveals their keys or signing the pubkey when you share your key (which Bob wouldn't be able to do without Alice's help for B' = B - A)
11:31 < maaku> But the better way is to use a key aggregation scheme that incorporates delinearization to structurally remove this weakness, so there is absolutely no foot-gun opportunities at all. That is what MuSig does.
11:33 < maaku> I think the libsecp256k1 authors would rather only reveal API endpoints which do things that are secure-by-default with foot-gun safeties.
11:34 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #secp256k1     
11:35 < maaku> It is not a crypto toolkit which just exposes a bunch of low-level APIs, nor is it meant to be. It instead exposes semantically meaningful but still generally useful APIs that generally compose together in safe ways
11:43 < sipa> Indeed; that's not only to avoid footguns though - it's also better for usability and performance
11:44 < sipa> libsecp256k1's internal representations are never exposed publicly
11:44 < maaku> or shouldn't be -- as noted the naive pubkey addition api is exposed
11:45 < sipa> right, we should probably remove that
11:45 < maaku> yup     
11:45 < sipa> though it doesn't actually expose the internal public key representation, which is far more efficient than the 32-byte encoding
11:45 < sipa> for example if for whatever reason you'd want to implement a higher-level protocol that needed to implement an addition between 3 keys, using the existing combine function would be slow
11:46 < sipa> probably around a factor 2 slower than implementing the protocol natively
11:46 < sipa> because to report back a public key, the jacobian->affine transformation needs to be performed, which is many times slower than the actual addition
11:46 < sipa> if you'd implement A+B+C by invoking combine twice, that transformation would need to be done twice
11:53 < sipa> this is just to say: even if there seems to be some low-level API that lets you build a higher-level protocol, it may be less efficient than what is possible natively
11:55 < gmaxwell> there is a conflict: if you exposed the LOWEST level interface possible, then perhaps that isn't so, but then you've gone and made all the internal representations part of the interface, which may prevent future improvments.
20:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]     
20:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1     
23:19 < kallewoof> sipa: combine_pubkeys takes an array of keys, so you technically don't have to call combine twice. (minor, i know)
23:20 < kallewoof> maaku: yeah, I know that's the case. But e.g. adding a pubkey to a hash of a pubkey and a script (taproot) doesn't seem to suffer from this problem. It does suffer from the problem only in that the original pubkey can't securely be a multisig-pubkey due to the B' thing you mentioend.
23:21 < kallewoof> As for performance, I don't really care too much about that for a debugger. It can be several x slower than the production platform without it causing issues unless you're debugging something monstrous.
23:22 < kallewoof> I know secp256k1 wants to be as efficient and streamlined as possible, so my argument doesn't really hold very strongly, but it feels like you can do a lot of fun things with taproot-style approach, so it'd be a pity if the public interface limits you too much.
23:24 < gmaxwell> A lot of fun things are totally insecure; for example the taproot like construction is insecure unless the pubkey you're adding to iss included in the hash... and the first people to suggest such a thing did not include it. Our public interface would be low quality if it was especially footgunny.
23:53 < sipa> kallewoof: did you know that by merely being able to add keys together and negating them, you can build a key negotiation protocol that lets any set of combinations of participants sign for something ;)
23:53 < kallewoof> sipa: ...like a k-of-n?
23:53 < sipa> and more.
23:54 < sipa> there are even more footguns there, but it's incredibly powerful
23:54 < kallewoof> is that the thing gmaxwell claims can replace all scripts in the future? (the and/or thing)
23:54 < sipa> well, it can't encode locktimes
23:54 < kallewoof> maybe I misunderstood that part, but it sounded like that was what he was saying (yeah, true)
23:55 < sipa> or hash preinages (but those are partially replacable with adapter signatures for some use cases)
23:56 < sipa> but say you want a 1-of-2 multisig
23:56 < sipa> assuming you have a secure communication channel between the two participants at setup time (so before the address is determined), there is an absolutely stupidly simple solution,
23:57 < sipa> A generates a private key, and gives that private key to B. done.
23:57 < kallewoof> Right
23:59 < sipa> a 2-of-2 is easy too: both A and B generate a key, and they share the pubkeys with eachother, and either sign the keys or use something like MuSig to combine them