--- Log opened Tue Nov 27 00:00:35 2018
00:05 -!- deusexbeer [~deusexbee@080-250-076-076-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!]
00:24 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds]
00:33 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1
03:03 -!- deusexbeer [~deusexbee@080-250-076-076-dynamic-pool-adsl.wbt.ru] has joined #secp256k1
03:03 -!- ken2812221 [~ken281222@1.200.219.124] has joined #secp256k1
03:05 -!- deusexbeer [~deusexbee@080-250-076-076-dynamic-pool-adsl.wbt.ru] has quit [Remote host closed the connection]
03:05 -!- deusexbeer [~deusexbee@080-250-076-076-dynamic-pool-adsl.wbt.ru] has joined #secp256k1
05:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 272 seconds]
06:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
06:19 -!- gelmutshmidt [~gelmutshm@188.113.19.47] has joined #secp256k1
07:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
07:23 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
11:28 < gmaxwell> is it sad that I'm just going to assume that multiparty schnorr implementation that was just posted is insecure without even looking at it?
11:29 < sipa> it says they implement 3-round musig
11:30 < sipa> and another scheme with a link to a paper by micali
11:36 < gmaxwell> oh does it only implement n of n? if so thats easier to not screw up.
11:47 < sipa> i haven't checked the code
11:47 < sipa> the second scheme is accountable subgroups, so i assume that is more than just n-of-n
11:55 < andytoshi> link?
11:56 < gmaxwell> From the list,
11:56 < gmaxwell> I am working for the past few months with collaborators (in cc) on providing Rust reference implementations to existing multi party schemes for Schnorr signatures [1]. This includes aggregated signatures, accountable signatures (which for n out of n are multi-signatures) and threshold signatures (wip).
11:56 < gmaxwell> The project can be found here: https://github.com/KZen-networks/multi-party-schnorr .
11:56 < gmaxwell> We aim that if the protocol is run in a configuration of a single party it will be bip-schnorr [2] compliant.
14:04 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
14:05 < ddustin> Are signatures the same for the same key / hash or do they have some random element?
14:06 < sipa> ddustin: that's a trick question
14:06 < sipa> signatures have a random element
14:06 < sipa> but it is computed deterministically from the message and private key in practice
14:06 < sipa> ddustin: so there are multiple valid signatures for a given pubkey/message
14:07 < sipa> but actual implementations will always create the same one
14:07 < ddustin> Ah I see secp256k1_ecdsa_sign takes a nonce function
14:07 < gmaxwell> Discrete log signatures have a mandatory secret random component. Since it's secret you can generate it any realistic way you want, so long as you are cryptographically unlikely to use the same random value for different messages and so long as no one else can predict what one you used.
14:07 < sipa> note that it isn't possible to verify that a particular signature was generated using a particular nonce function
14:08 < sipa> (unless zkproofs...)
14:09 < ddustin> Cool thanks for the explanation
14:11 < ddustin> gmaxwell: "so long as no one else can predict what one you used." <- If the random component is guessed can people discover your private key or something?
14:18 < sipa> ddustin: exactly
14:58 -!- ken2812221_ [~ken281222@1.200.219.124] has joined #secp256k1
15:01 -!- ken2812221 [~ken281222@1.200.219.124] has quit [Ping timeout: 268 seconds]
15:24 -!- gelmutshmidt [~gelmutshm@188.113.19.47] has quit [Remote host closed the connection]
17:50 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 245 seconds]
18:55 -!- _cryptodesktop_i [~John@91.245.77.21] has joined #secp256k1
19:29 -!- _cryptodesktop_i [~John@91.245.77.21] has quit [Ping timeout: 250 seconds]
19:54 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1
21:58 < ddustin> Hm so if I have an r and an s value, what's the correct way to load them into a signature?
21:58 < ddustin> I thought secp256k1_ecdsa_signature_parse_compact would do it, but apparently that struggles when the first bit of either is a 1
21:59 < ddustin> The only other method I can see is manually doing a DER encoding -- is that the correct method?
21:59 < ddustin> s/either/s/ --- I didn't test the first bit of r being or not being a 1
22:03 < gmaxwell> ddustin: if s is high your signature is not valid according to libsecp256k1.
22:04 < ddustin> Oh! Interesting. What is supposed to be done in that case -- generate another signature with new entropy?
22:04 < gmaxwell> ddustin: https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L415
22:04 < gmaxwell> ddustin: libsecp256k1 will not genrate a high s signature.
22:06 < ddustin> Huh okay interesting! So If I use secp256k1_ecdsa_signature_normalize as mentioned int he docs, will this cause problems for signing bitcoin transactions?
22:06 < gmaxwell> It's not clear what you mean by use.
22:07 < gmaxwell> Bitcoin signatures must be lowS.  The signing function in libsecp256k1 will always generate in that form.
22:07 < ddustin> The signature is coming from another source that doesn't follow this rule =\
22:07 < sipa> then you first need to normalize, and then verify
22:07 < ddustin> The comments say "If you need to accept ECDSA signatures from sources that do not obey this rule, apply secp256k1_ecdsa_signature_normalize to the signature prior to validation, but be aware that doing so results in malleable signatures."
22:08 < sipa> yes
22:08 < sipa> by definition
22:08 < sipa> the normalize function malleates
22:08 < gmaxwell> ddustin: I'm worried that you're doing something like taking a bitcoin transaction from elsewhere, then validating it using normalize. If so, you'd accept transactions the network rejects.
22:09 < sipa> ddustin: a way to see is that every signature has two equivalent forms, lows and highs, and anyone can freely convert between them
22:09 < gmaxwell> if you're not doing anything with bitcoin (or another new protocol where you control the behavior), then sure, preprocess the signatures with normalize.
22:09 < ddustin> gmaxwell: I'm signing fresh transactions. Sounds like normalizing here would just make the signature rejected by the network then?
22:09 < sipa> to prevent malleability, libsecp only accepts the lows form
22:10 < sipa> ddustin: if you sign using something elsez you *must* nornalize it for use in bitcoin
22:10 < sipa> because bitcoin requires lows signatures
22:10 < gmaxwell> ddustin: if you're signing transactions for bitcoin, you must either normalize the signatures before giving them to bitcoin nodes, or fix the signer to produce correct bitcoin signatures on its own.
22:11 < sipa> if libsecp rejects your signature, so will the network
22:11 < ddustin> Ah okay I think I'm starting to understand. Thanks a bunch.
22:14 < gmaxwell> sipa: I wonder if libsecp256k1 had hit some google penality, this search didn't return it at all: https://www.google.com/search?q="To+avoid+accepting+malleable+signatures"
22:20 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
--- Log closed Wed Nov 28 00:00:36 2018