12019-11-24T00:59:46  *** jonatack_ has joined ##taproot-bip-review
 22019-11-24T01:03:20  *** jonatack has quit IRC
 32019-11-24T01:08:57  *** jonatack_ has quit IRC
 42019-11-24T03:08:09  <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?
 52019-11-24T03:08:45  <nothingmuch> if i'm not mistaken the conversion requires the same amount of work as non-batch verification?
 62019-11-24T03:21:57  <sipa> nothingmuch: in some transmission mediums you vastly prefer low bandwidth over low CPU costs
 72019-11-24T03:24:18  <sipa> say, for transmission over a satellite connection
 82019-11-24T03:24:41  <sipa> so it might be advantageous to have a scheme that is flexible, and can use both mechanisms
 92019-11-24T03:25:12  <sipa> unfortunately 128-bit hashes also come with unclear security properties
102019-11-24T03:34:40  <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
112019-11-24T03:46:30  <gmaxwell> nothingmuch: coversion from R,s to e,s requires only hashing.
122019-11-24T03:47:47  <gmaxwell> though for bitcoin it would be costly to do for historical blocks because the 'messages' are not readily available.
132019-11-24T03:48:46  <gmaxwell> More than just 'less clear' it seems much less likely that reduced hashes are at least as strong as the existing ECDSA signatures.
142019-11-24T03:49:53  <sipa> indeed
152019-11-24T03:50:30  <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"
162019-11-24T03:51:59  <nothingmuch> gmaxwell: i was wondering if (e, s) at the consensus level necessarily implies that the advantage of batching is lost
172019-11-24T03:52:45  <sipa> nothingmuch: no, the rules are equivalent
182019-11-24T03:52:56  <sipa> it's just a matter of encoding
192019-11-24T03:53:05  <sipa> bit you can validate both forms in a compatible way
202019-11-24T03:53:53  <nothingmuch> in that case i'm unclear on the note about the hashing requiring no EC operations with the R variant
212019-11-24T03:56:36  <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?
222019-11-24T03:57:00  <sipa> converting (e, s) to (R, s) is costly
232019-11-24T03:57:12  <sipa> converting from (R, s) to (e, s) is cheap
242019-11-24T03:57:21  <sipa> (R, s) supports batch validation
252019-11-24T03:57:42  <sipa> (e, s) is more compact if a short hash is used (which we won't for security reasons)
262019-11-24T03:58:57  <nothingmuch> ok, in that case i think my patch is correct, PRing
272019-11-24T03:58: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.
282019-11-24T03:59:22  <gmaxwell> But for ECC that advantage vanishes.
292019-11-24T04:00:40  <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.
302019-11-24T04:06:59  <sipa> if you fiat-shamir transform the schnorr identification protocol, you get R,s
312019-11-24T09:32:13  *** jonatack has joined ##taproot-bip-review
322019-11-24T10:22:18  *** b10c has joined ##taproot-bip-review
332019-11-24T13:36:24  *** Chris_Stewart_5 has joined ##taproot-bip-review
342019-11-24T13:37:55  *** jonatack has quit IRC
352019-11-24T13:47:04  *** b10c has quit IRC
362019-11-24T14:09:28  *** Chris_Stewart_5 has quit IRC
372019-11-24T14:19:17  *** shesek has quit IRC
382019-11-24T14:44:05  *** jonatack has joined ##taproot-bip-review
392019-11-24T15:01:59  *** Chris_Stewart_5 has joined ##taproot-bip-review
402019-11-24T15:49:15  *** shesek has joined ##taproot-bip-review
412019-11-24T15:49:16  *** shesek has joined ##taproot-bip-review
422019-11-24T16:09:38  *** shesek has quit IRC
432019-11-24T16:19:46  *** shesek has joined ##taproot-bip-review
442019-11-24T16:19:46  *** shesek has joined ##taproot-bip-review
452019-11-24T16:33:53  *** davterra has quit IRC
462019-11-24T16:54:34  <waxwing> sipa, i'm curios, why do you say that? i don't see why both aren't valid outcomes from that process (both are verifiable).
472019-11-24T16:57:22  <sipa> waxwing: the schnorr identification protocol is A picks k and sends R=kG, B picks a random e and sends it, A sends s=k+e*x
482019-11-24T16:57:24  <waxwing> gmaxwell, in stuff like AOS and your later borromean construction, and i think some other similar constructs, i think using e- helps to allow compaction, because the transcript being hashed is much longer. i guess it's not relevant to this conversation, but seems like an interesting detail.
492019-11-24T16:57:28  <sipa> right?
502019-11-24T16:57:35  <waxwing> right
512019-11-24T16:58:13  <sipa> so what A sends is R,s, and e is replaced with a hash of R in the fiat-shamir transform
522019-11-24T16:58:40  <waxwing> the transcript is (R, e, s); but providing either e- or R- is sufficient for proof under the given hardness assumptions. (in the transformed case, where e is a derived quantity)
532019-11-24T16:59:10  <sipa> of course, we know it is equivalent
542019-11-24T16:59:31  <sipa> but what A sends is R,s
552019-11-24T16:59:51  <waxwing> in the SIDP. sure.
562019-11-24T17:02:03  <sipa> maybe my point is that the "most natural" fiat-shamir transformation of SIDP results in the (R,s) form
572019-11-24T17:07:28  *** b10c has joined ##taproot-bip-review
582019-11-24T17:08:26  <waxwing> maybe. 'commitment, (implicit challenge), response'. but seems like a stretch to make the distinction. perhaps you can say it's cleaner, and that's also indirectly why batch verification is possible.
592019-11-24T17:30:40  *** davterra has joined ##taproot-bip-review
602019-11-24T17:33:16  *** Chris_Stewart_5 has quit IRC
612019-11-24T17:34:55  *** andrewtoth_ has joined ##taproot-bip-review
622019-11-24T18:07:19  *** Chris_Stewart_5 has joined ##taproot-bip-review
632019-11-24T18:49:48  *** andrewtoth_ has quit IRC
642019-11-24T19:05:22  *** andrewtoth_ has joined ##taproot-bip-review
652019-11-24T19:13:17  *** shesek has quit IRC
662019-11-24T19:37:33  *** jonatack has quit IRC
672019-11-24T20:07:14  *** Chris_Stewart_5 has quit IRC
682019-11-24T20:10:57  *** jonatack has joined ##taproot-bip-review
692019-11-24T22:15:43  *** Chris_Stewart_5 has joined ##taproot-bip-review
702019-11-24T22:18:48  *** shesek has joined ##taproot-bip-review
712019-11-24T22:18:48  *** shesek has joined ##taproot-bip-review
722019-11-24T22:23:11  *** shesek has quit IRC
732019-11-24T22:24:29  *** shesek has joined ##taproot-bip-review
742019-11-24T22:25:37  *** Chris_Stewart_5 has quit IRC
752019-11-24T22:55:39  *** b10c has quit IRC
762019-11-24T23:13:09  *** pinheadmz has quit IRC
772019-11-24T23:35:58  *** Chris_Stewart_5 has joined ##taproot-bip-review