12019-12-08T00:35:55  *** Chris_Stewart_5 has joined ##taproot-bip-review
 22019-12-08T00:57:57  *** jeremyrubin has quit IRC
 32019-12-08T01:05:45  *** mryandao has quit IRC
 42019-12-08T01:08:50  *** mryandao has joined ##taproot-bip-review
 52019-12-08T02:40:23  *** Chris_Stewart_5 has quit IRC
 62019-12-08T02:56:15  *** arik_ has quit IRC
 72019-12-08T02:57:44  *** Chris_Stewart_5 has joined ##taproot-bip-review
 82019-12-08T03:13:15  *** Chris_Stewart_5 has quit IRC
 92019-12-08T03:32:44  *** ZmnSCPxj has joined ##taproot-bip-review
102019-12-08T03:36:06  <ZmnSCPxj> Given that R is sometimes called an "ephemeral key", why cannot we compose R using the same function as MuSig pubkey aggregation?
112019-12-08T03:36:54  <ZmnSCPxj> i.e. MuSig(A, B) = h(sort({A, B}) | A) * A + h(sort({A, B}) | B) * B
122019-12-08T03:37:28  <ZmnSCPxj> Then just use the same for R contributions from each aggregate member?
132019-12-08T03:39:20  <ZmnSCPxj> Hmmm.
142019-12-08T03:39:38  <ZmnSCPxj> Because you can still perform a Wagner attack on this method of aggregating R.
152019-12-08T03:40:27  <aj> it's usually H( H(A,B), 1 )  not H(sort(A,B), A) isn't it? (to cope with duplicate keys)
162019-12-08T03:41:50  <ZmnSCPxj> My understanding of MuSig is that it requires some canonical ordering of the keys, which is done by sorting the keys
172019-12-08T03:42:06  <ZmnSCPxj> And duplicate keys are handled fine by a sort, they just get duplicated right next to each other
182019-12-08T03:42:27  <aj> sure, but the |A part doesn't distinguish between them
192019-12-08T03:46:44  <ZmnSCPxj> I see, but MuSig paper uses that.
202019-12-08T03:47:38  <ZmnSCPxj> a[i] = h[agg](L, X[i]), then MuSig(X[1..n]) = sum where i = 1 to n of a[i] * X[i]
212019-12-08T03:48:12  <ZmnSCPxj> And L is "uniquely encoded, e.g. lexicographical order", i.e. sorted
222019-12-08T03:50:01  *** jeremyrubin has joined ##taproot-bip-review
232019-12-08T03:50:22  <aj> yeah; but requires X[i] to be distinct. https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/musig/musig.md uses ,i and assumes P_i have some fixed ordering not necessarily sorted, i think
242019-12-08T03:53:18  <aj> (i mean having the same key twice at the same level in a musig does seem pretty daft)
252019-12-08T03:56:57  *** jeremyrubin has quit IRC
262019-12-08T03:59:53  <gmaxwell> SECURE HARDER. TWO KEYS MORE STRONG THAN ONE KEY!
272019-12-08T04:05:10  <aj> you've heard of 2-of-3 multisig, now try our battle hardened 5-of-3 multisig?
282019-12-08T04:06:25  <aj> provides full access to all funds even with total loss of up to two of the original three keys!
292019-12-08T04:18:06  *** arik_ has joined ##taproot-bip-review
302019-12-08T04:24:17  *** jeremyrubin has joined ##taproot-bip-review
312019-12-08T04:53:36  *** davterra has quit IRC
322019-12-08T08:54:33  *** jonatack has quit IRC
332019-12-08T09:13:14  *** b10c has joined ##taproot-bip-review
342019-12-08T10:00:10  *** arik_ has quit IRC
352019-12-08T10:00:12  *** mryandao has quit IRC
362019-12-08T10:00:52  *** mryandao has joined ##taproot-bip-review
372019-12-08T10:26:38  *** mryandao_ has joined ##taproot-bip-review
382019-12-08T10:29:33  *** mryandao- has joined ##taproot-bip-review
392019-12-08T10:29:36  *** mryandao has quit IRC
402019-12-08T10:31:56  *** mryandao_ has quit IRC
412019-12-08T11:08:38  *** b10c has quit IRC
422019-12-08T11:16:35  *** belcher has quit IRC
432019-12-08T11:25:23  *** belcher has joined ##taproot-bip-review
442019-12-08T11:34:28  *** andytoshi has quit IRC
452019-12-08T11:46:49  *** ghost43 has quit IRC
462019-12-08T11:47:10  *** ghost43 has joined ##taproot-bip-review
472019-12-08T12:51:41  *** b10c has joined ##taproot-bip-review
482019-12-08T13:09:11  *** takinbo has quit IRC
492019-12-08T13:13:51  *** takinbo has joined ##taproot-bip-review
502019-12-08T13:57:18  *** Chris_Stewart_5 has joined ##taproot-bip-review
512019-12-08T15:51:57  *** jonatack has joined ##taproot-bip-review
522019-12-08T16:25:32  *** _andrewtoth_ has joined ##taproot-bip-review
532019-12-08T16:38:37  *** Chris_Stewart_5 has quit IRC
542019-12-08T16:40:00  <elichai2> What do people think about adding `r > 0` and `s > 0` to the verification algorithm in bip-schnorr https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki#verification
552019-12-08T16:45:47  <elichai2> altough because P and R are in the hash then technically not verifying this doesn't allow you to "solve" for anything to create fake sigs AFAICT
562019-12-08T16:47:03  <elichai2> (and I don't like the amount of PRs to the repo :/ it's a BIP it should try to be short and readable IMHO)
572019-12-08T18:25:26  *** davterra has joined ##taproot-bip-review
582019-12-08T19:15:35  *** arik_ has joined ##taproot-bip-review
592019-12-08T19:31:05  *** arik_ has quit IRC
602019-12-08T19:31:44  *** arik_ has joined ##taproot-bip-review
612019-12-08T19:40:18  *** arik_ has quit IRC
622019-12-08T19:41:30  *** arik_ has joined ##taproot-bip-review
632019-12-08T19:50:17  *** arik_ has quit IRC
642019-12-08T19:51:13  *** arik_ has joined ##taproot-bip-review
652019-12-08T19:54:30  *** arik_ has quit IRC
662019-12-08T20:03:03  *** davterra has quit IRC
672019-12-08T20:07:21  *** davterra has joined ##taproot-bip-review
682019-12-08T20:10:59  *** b10c has quit IRC
692019-12-08T20:13:29  *** dr-orlovsky has quit IRC
702019-12-08T20:23:07  *** dr-orlovsky has joined ##taproot-bip-review
712019-12-08T21:03:34  *** ZmnSCPxj_ has joined ##taproot-bip-review
722019-12-08T21:06:01  *** ZmnSCPxj has quit IRC
732019-12-08T21:37:19  *** Chris_Stewart_5 has joined ##taproot-bip-review
742019-12-08T22:51:37  *** Chris_Stewart_5 has quit IRC