--- Day changed Sat Nov 23 2019
01:01 -!- schmidty [sid297174@gateway/web/irccloud.com/x-xuurqbzdynbubgql] has quit [Ping timeout: 264 seconds]     
01:03 -!- midnight [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds]     
01:04 -!- schmidty [sid297174@gateway/web/irccloud.com/x-iawktsydxwbwzjlt] has joined ##taproot-bip-review     
01:16 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined ##taproot-bip-review     
02:02 < nickler> harding: I don't think that it would need an additional roundtrip. In your example, Alice sends her nonce along with the `update_add_htlc` message and Bob can reply with both his nonce and his partial signature in a single message.
02:04 < nickler> The scriptless scripts multi-hop locks writeup should clarify how to deal with MuSig rounds https://github.com/ElementsProject/scriptless-scripts/pull/6 (but I'm certainly no expert on the BOLTs)
02:29 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]     
02:30 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review     
04:16 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
04:59 -!- jonatack_ [~jon@37.167.26.27] has joined ##taproot-bip-review     
05:03 -!- jonatack [~jon@37.171.25.26] has quit [Ping timeout: 276 seconds]     
05:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
05:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
05:53 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review     
06:10 -!- pinheadmz_ [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-bip-review     
06:13 -!- pinheadmz [~matthewzi@91.132.137.236] has quit [Ping timeout: 240 seconds]     
06:13 -!- pinheadmz_ is now known as pinheadmz     
06:24 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]     
06:24 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review     
06:24 -!- shesek [~shesek@185.3.145.80] has quit [Changing host]     
06:24 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review     
06:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
06:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]     
06:44 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has joined ##taproot-bip-review     
07:03 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds]     
07:06 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review     
07:06 -!- shesek [~shesek@185.3.145.80] has quit [Changing host]     
07:06 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review     
07:34 < harding> nickler: in the current protocol, as I understand it, Alice might send multiple `update_add_htlc` messages to Bob before Bob returns a signature (see https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#normal-operation).  Would it be safe to allow Bob to choose which update he generates a partial signature for?  E.g., A & B have a series of pre-shared nonce commitment pairs so that they can use a
07:34 < harding> different nonce in each update.  For update_0, Alice sends the message and her nonce, but Bob doesn't reply immediately.  Alice receives another HTLC to route (update_1), sends the message and the next nonce in the series of pre-committed nonces, and now Bob has two messages each with a different nonce from Alice.  Bob can choose either message and its associated nonce, so he can (per your blog post) "choose the message after
07:34 < harding> the combined public nonce is known and is therefore able to bias the hash function".  Admittedly, Bob can only choose messages from the values Alice sent him and he gets whatever nonce comes with them (derived from his and Alice's pre-committed nonces), so he's much more limited in his selection than if he was able to brute force locally, but it still feels to me like a variation on the attack you describe.
08:01 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds]     
08:02 -!- rottensox_ [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review     
08:04 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 250 seconds]     
08:04 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review     
08:04 -!- shesek [~shesek@185.3.145.80] has quit [Changing host]     
08:04 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review     
08:07 -!- rottensox_ is now known as rottensox     
08:08 -!- shesek [~shesek@unaffiliated/shesek] has quit [Excess Flood]     
08:08 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review     
08:08 -!- shesek [~shesek@185.3.145.80] has quit [Changing host]     
08:08 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review     
08:12 -!- jonatack_ [~jon@37.167.26.27] has quit [Read error: Connection reset by peer]     
08:13 -!- jonatack_ [~jon@37.167.26.27] has joined ##taproot-bip-review     
08:22 -!- pinheadmz_ [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-bip-review     
08:25 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds]     
08:25 -!- pinheadmz_ is now known as pinheadmz     
08:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds]     
08:35 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review     
08:35 -!- shesek [~shesek@185.3.145.80] has quit [Changing host]     
08:35 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review     
08:52 -!- jonatack_ [~jon@37.167.26.27] has quit [Quit: jonatack_]     
08:52 -!- jonatack [~jon@37.167.26.27] has joined ##taproot-bip-review     
08:54 -!- rottensox_ [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review     
08:56 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 246 seconds]     
09:34 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has quit [Remote host closed the connection]     
09:54 -!- jonatack [~jon@37.167.26.27] has quit [Read error: Connection reset by peer]     
10:31 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
12:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds]     
12:57 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review     
12:57 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]     
12:58 -!- sosthene [~sosthene@88.191.20.124] has quit [Ping timeout: 265 seconds]     
13:04 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-bip-review     
13:04 -!- sosthene [~sosthene@88.191.20.124] has joined ##taproot-bip-review     
13:27 -!- rottensox_ is now known as rottensox     
13:41 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
13:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]     
14:44 -!- b10c [~Thunderbi@mue-88-130-54-050.dsl.tropolys.de] has joined ##taproot-bip-review     
14:54 -!- jonatack [~jon@37.167.71.155] has joined ##taproot-bip-review     
15:11 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Quit: Bye]     
15:34 -!- b10c [~Thunderbi@mue-88-130-54-050.dsl.tropolys.de] has quit [Ping timeout: 240 seconds]     
16:59 -!- jonatack_ [~jon@37.164.33.234] has joined ##taproot-bip-review     
17:03 -!- jonatack [~jon@37.167.71.155] has quit [Ping timeout: 276 seconds]     
17:08 -!- jonatack_ [~jon@37.164.33.234] has quit [Read error: Connection reset by peer]     
19:08 < nothingmuch> gmaxwell: using (R, s) variant with short hashes converted to (e, s) for storage/communication, under what circumstances would the conversion be desirable to avoid negating the advantage of batch verification?
19:08 < nothingmuch> if i'm not mistaken the conversion requires the same amount of work as non-batch verification?
19:21 < sipa> nothingmuch: in some transmission mediums you vastly prefer low bandwidth over low CPU costs
19:24 < sipa> say, for transmission over a satellite connection
19:24 < sipa> so it might be advantageous to have a scheme that is flexible, and can use both mechanisms
19:25 < sipa> unfortunately 128-bit hashes also come with unclear security properties
19:34 < nothingmuch> sipa: thanks, that clarifies it. i'm working on a minor clarification to the BIP to provide more complete rationale for the choice of R variant based on the more conservative assumptions of full sized hashes and wanted to make sure i understood the choice to not mention that possibility
19:46 < gmaxwell> nothingmuch: coversion from R,s to e,s requires only hashing.
19:47 < gmaxwell> though for bitcoin it would be costly to do for historical blocks because the 'messages' are not readily available.
19:48 < gmaxwell> More than just 'less clear' it seems much less likely that reduced hashes are at least as strong as the existing ECDSA signatures.
19:49 < sipa> indeed
19:50 < sipa> and part of our rationale isn't just the usual "it is secure enough", it is "this is obviously not weaker than what we already have"
19:51 < nothingmuch> gmaxwell: i was wondering if (e, s) at the consensus level necessarily implies that the advantage of batching is lost
19:52 < sipa> nothingmuch: no, the rules are equivalent
19:52 < sipa> it's just a matter of encoding
19:53 < sipa> bit you can validate both forms in a compatible way
19:53 < nothingmuch> in that case i'm unclear on the note about the hashing requiring no EC operations with the R variant
19:56 < nothingmuch> i understand that they are equivalent due to the bijection, but that implied to me transactions use the (e, s) variant batch verification can only be done by first converting to the (R, s) variant, which is as costly as verification?
19:57 < sipa> converting (e, s) to (R, s) is costly
19:57 < sipa> converting from (R, s) to (e, s) is cheap
19:57 < sipa> (R, s) supports batch validation
19:57 < sipa> (e, s) is more compact if a short hash is used (which we won't for security reasons)
19:58 < nothingmuch> ok, in that case i think my patch is correct, PRing
19:58 < gmaxwell> The only reason I think anyone ever really talks in terms of e,s is that for non-ECC DL, serializations of the group elements are enormous, and 'e,s' is much more communication efficient _without_ any particularly sketchy security properties.
19:59 < gmaxwell> But for ECC that advantage vanishes.
20:00 < gmaxwell> the several possible routes that I'm aware of for derriving a schnorr signature from first principles all end up with an R,s signature, I think.
20:06 < sipa> if you fiat-shamir transform the schnorr identification protocol, you get R,s