1 2019-11-24T00:59:46  *** jonatack_ has joined ##taproot-bip-review
 2 2019-11-24T01:03:20  *** jonatack has quit IRC
 3 2019-11-24T01:08:57  *** jonatack_ has quit IRC
 4 2019-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?
 5 2019-11-24T03:08:45  <nothingmuch> if i'm not mistaken the conversion requires the same amount of work as non-batch verification?
 6 2019-11-24T03:21:57  <sipa> nothingmuch: in some transmission mediums you vastly prefer low bandwidth over low CPU costs
 7 2019-11-24T03:24:18  <sipa> say, for transmission over a satellite connection
 8 2019-11-24T03:24:41  <sipa> so it might be advantageous to have a scheme that is flexible, and can use both mechanisms
 9 2019-11-24T03:25:12  <sipa> unfortunately 128-bit hashes also come with unclear security properties
10 2019-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
11 2019-11-24T03:46:30  <gmaxwell> nothingmuch: coversion from R,s to e,s requires only hashing.
12 2019-11-24T03:47:47  <gmaxwell> though for bitcoin it would be costly to do for historical blocks because the 'messages' are not readily available.
13 2019-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.
14 2019-11-24T03:49:53  <sipa> indeed
15 2019-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"
16 2019-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
17 2019-11-24T03:52:45  <sipa> nothingmuch: no, the rules are equivalent
18 2019-11-24T03:52:56  <sipa> it's just a matter of encoding
19 2019-11-24T03:53:05  <sipa> bit you can validate both forms in a compatible way
20 2019-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
21 2019-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?
22 2019-11-24T03:57:00  <sipa> converting (e, s) to (R, s) is costly
23 2019-11-24T03:57:12  <sipa> converting from (R, s) to (e, s) is cheap
24 2019-11-24T03:57:21  <sipa> (R, s) supports batch validation
25 2019-11-24T03:57:42  <sipa> (e, s) is more compact if a short hash is used (which we won't for security reasons)
26 2019-11-24T03:58:57  <nothingmuch> ok, in that case i think my patch is correct, PRing
27 2019-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.
28 2019-11-24T03:59:22  <gmaxwell> But for ECC that advantage vanishes.
29 2019-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.
30 2019-11-24T04:06:59  <sipa> if you fiat-shamir transform the schnorr identification protocol, you get R,s
31 2019-11-24T09:32:13  *** jonatack has joined ##taproot-bip-review
32 2019-11-24T10:22:18  *** b10c has joined ##taproot-bip-review
33 2019-11-24T13:36:24  *** Chris_Stewart_5 has joined ##taproot-bip-review
34 2019-11-24T13:37:55  *** jonatack has quit IRC
35 2019-11-24T13:47:04  *** b10c has quit IRC
36 2019-11-24T14:09:28  *** Chris_Stewart_5 has quit IRC
37 2019-11-24T14:19:17  *** shesek has quit IRC
38 2019-11-24T14:44:05  *** jonatack has joined ##taproot-bip-review
39 2019-11-24T15:01:59  *** Chris_Stewart_5 has joined ##taproot-bip-review
40 2019-11-24T15:49:15  *** shesek has joined ##taproot-bip-review
41 2019-11-24T15:49:16  *** shesek has joined ##taproot-bip-review
42 2019-11-24T16:09:38  *** shesek has quit IRC
43 2019-11-24T16:19:46  *** shesek has joined ##taproot-bip-review
44 2019-11-24T16:19:46  *** shesek has joined ##taproot-bip-review
45 2019-11-24T16:33:53  *** davterra has quit IRC
46 2019-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).
47 2019-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
48 2019-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.
49 2019-11-24T16:57:28  <sipa> right?
50 2019-11-24T16:57:35  <waxwing> right
51 2019-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
52 2019-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)
53 2019-11-24T16:59:10  <sipa> of course, we know it is equivalent
54 2019-11-24T16:59:31  <sipa> but what A sends is R,s
55 2019-11-24T16:59:51  <waxwing> in the SIDP. sure.
56 2019-11-24T17:02:03  <sipa> maybe my point is that the "most natural" fiat-shamir transformation of SIDP results in the (R,s) form
57 2019-11-24T17:07:28  *** b10c has joined ##taproot-bip-review
58 2019-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.
59 2019-11-24T17:30:40  *** davterra has joined ##taproot-bip-review
60 2019-11-24T17:33:16  *** Chris_Stewart_5 has quit IRC
61 2019-11-24T17:34:55  *** andrewtoth_ has joined ##taproot-bip-review
62 2019-11-24T18:07:19  *** Chris_Stewart_5 has joined ##taproot-bip-review
63 2019-11-24T18:49:48  *** andrewtoth_ has quit IRC
64 2019-11-24T19:05:22  *** andrewtoth_ has joined ##taproot-bip-review
65 2019-11-24T19:13:17  *** shesek has quit IRC
66 2019-11-24T19:37:33  *** jonatack has quit IRC
67 2019-11-24T20:07:14  *** Chris_Stewart_5 has quit IRC
68 2019-11-24T20:10:57  *** jonatack has joined ##taproot-bip-review
69 2019-11-24T22:15:43  *** Chris_Stewart_5 has joined ##taproot-bip-review
70 2019-11-24T22:18:48  *** shesek has joined ##taproot-bip-review
71 2019-11-24T22:18:48  *** shesek has joined ##taproot-bip-review
72 2019-11-24T22:23:11  *** shesek has quit IRC
73 2019-11-24T22:24:29  *** shesek has joined ##taproot-bip-review
74 2019-11-24T22:25:37  *** Chris_Stewart_5 has quit IRC
75 2019-11-24T22:55:39  *** b10c has quit IRC
76 2019-11-24T23:13:09  *** pinheadmz has quit IRC
77 2019-11-24T23:35:58  *** Chris_Stewart_5 has joined ##taproot-bip-review