1 2019-11-04T01:00:29  <takinbo> xoyi-: hey!
  2 2019-11-04T01:08:45  *** ilan has joined ##taproot-bip-review
  3 2019-11-04T01:30:08  *** ilan has quit IRC
  4 2019-11-04T01:53:06  *** nick_fre_ has joined ##taproot-bip-review
  5 2019-11-04T01:55:43  *** nick_freeman has quit IRC
  6 2019-11-04T02:34:37  *** nick_freeman has joined ##taproot-bip-review
  7 2019-11-04T02:37:23  *** nick_fre_ has quit IRC
  8 2019-11-04T04:57:50  *** murch has joined ##taproot-bip-review
  9 2019-11-04T07:34:32  *** codaelux has joined ##taproot-bip-review
 10 2019-11-04T07:36:15  *** jonatack has joined ##taproot-bip-review
 11 2019-11-04T07:51:39  *** xoyi- has joined ##taproot-bip-review
 12 2019-11-04T08:20:58  *** jonatack has quit IRC
 13 2019-11-04T08:22:37  *** jonatack has joined ##taproot-bip-review
 14 2019-11-04T08:44:53  *** luke-jr has quit IRC
 15 2019-11-04T08:48:24  *** luke-jr has joined ##taproot-bip-review
 16 2019-11-04T09:10:11  *** jamieasefa has joined ##taproot-bip-review
 17 2019-11-04T09:44:47  *** jamieasefa has quit IRC
 18 2019-11-04T10:54:45  *** orfeas has joined ##taproot-bip-review
 19 2019-11-04T11:34:12  *** willcl_ark has joined ##taproot-bip-review
 20 2019-11-04T12:47:23  *** nothingmuch has joined ##taproot-bip-review
 21 2019-11-04T13:24:59  *** jonatack has quit IRC
 22 2019-11-04T13:53:49  *** Codaelux1 has joined ##taproot-bip-review
 23 2019-11-04T13:54:06  *** Codaelux1 has left ##taproot-bip-review
 24 2019-11-04T14:04:22  *** pyskl has joined ##taproot-bip-review
 25 2019-11-04T14:33:42  *** Chris_Stewart_5 has joined ##taproot-bip-review
 26 2019-11-04T14:36:25  *** diogosergio has joined ##taproot-bip-review
 27 2019-11-04T15:10:30  *** dmkathayat has joined ##taproot-bip-review
 28 2019-11-04T15:22:57  *** xoyi- has quit IRC
 29 2019-11-04T15:25:17  *** jb55 has joined ##taproot-bip-review
 30 2019-11-04T16:16:56  *** xoyi- has joined ##taproot-bip-review
 31 2019-11-04T16:19:15  *** waxwing has joined ##taproot-bip-review
 32 2019-11-04T16:22:48  *** jonatack has joined ##taproot-bip-review
 33 2019-11-04T16:51:15  *** diogosergio has quit IRC
 34 2019-11-04T17:03:09  *** diogosergio has joined ##taproot-bip-review
 35 2019-11-04T17:12:50  *** diogosergio has quit IRC
 36 2019-11-04T17:20:40  *** sosthene has joined ##taproot-bip-review
 37 2019-11-04T17:29:08  <sosthene> Hi there, is everyone already on the Slack? :)
 38 2019-11-04T17:29:55  <sipa> hell no.
 39 2019-11-04T17:30:05  <sipa> :)
 40 2019-11-04T17:30:26  <sosthene> very excited to be here!
 41 2019-11-04T17:42:25  *** orfeas has quit IRC
 42 2019-11-04T17:48:18  <harding> sosthene: hi!
 43 2019-11-04T17:58:36  <xoyi-> One thing I noticed, is that Greg's original Taproot announcement on the mailing list does not mention Schnorr at all. But isn't Schnorr's linearity property that makes Taproot possible?
 44 2019-11-04T17:58:53  <xoyi-> (not sure if I should be asking here or in my study group, or wait for the Q&A)
 45 2019-11-04T18:01:53  <sipa> xoyi-: gmaxwell's writeup does mention "We compute the 2-of-2 aggregate key C = A + B.  (Simplified; to protect against rogue key attacks you may want to use the MuSig key aggregation function [1])"; as those things aren't really (easily) possible with non-Schnorr-like signature schemes, I believe he meant that to be implied
 46 2019-11-04T18:04:10  <sipa> As long as the volume of questions here is low, I think it's fine to just ask them, but maybe others have a different opinion
 47 2019-11-04T18:04:46  <xoyi-> ah got it, thanks
 48 2019-11-04T18:04:48  <sipa> xoyi-: oh, wait, I think I'm confusing you
 49 2019-11-04T18:05:32  <sipa> Taproot is certainly possible with ECDSA as well, but much less useful, as you couldn't (easily) combine multiple public keys as the common path
 50 2019-11-04T18:06:27  <gmaxwell> it's not tecnically required, but it would be stupid to deploy any other way.
 51 2019-11-04T18:06:34  <gmaxwell> sipa: you can use multiply ecdsa.
 52 2019-11-04T18:06:39  <sipa> And if the common branch can only be a single key (rather than an aggreate of all parties, or a sufficient subset of them), Taproot's advantages go away
 53 2019-11-04T18:07:01  <gmaxwell> multiparty*
 54 2019-11-04T18:08:02  <sipa> xoyi-: Maybe your question is if Schnorr is necessary for the tweaking to work... that's not the case: as long as there is a single signer, you don't need the linearity property, as all the signer needs to do is tweak his private key equivalently
 55 2019-11-04T18:08:18  <sipa> gmaxwell: right, that too
 56 2019-11-04T18:10:28  <gmaxwell> sipa: even with multiple signers... with multiparty ecdsa... (ignoring the fact that multiparty ecdsa is obnoxious to implement)
 57 2019-11-04T18:11:30  <sipa> Right, the linearity property only makes things _easier_, it's not changing things from impossible to possible.
 58 2019-11-04T18:11:43  <gmaxwell> they _keys_ are still linear just fine...
 59 2019-11-04T18:12:00  <sipa> My point is that in case you give up on linearity and complex ECDSA multisigning, Taproot tweaking still works just fine.
 60 2019-11-04T18:12:22  <gmaxwell> indeed.
 61 2019-11-04T18:12:58  <gmaxwell> (well _tweaking_ needs a kind of key linearity)
 62 2019-11-04T18:13:10  <sipa> Right, but not signature linearty.
 63 2019-11-04T18:13:45  <gmaxwell> and, yes, in my writeup I didn't mention schnorr intentionally, since it isn't necessary. actually I think one of my emails even says that.
 64 2019-11-04T18:18:01  <gmaxwell> seems not, probably remembering saying it on irc.
 65 2019-11-04T18:18:09  *** diogosergio has joined ##taproot-bip-review
 66 2019-11-04T18:18:31  *** marcinja has joined ##taproot-bip-review
 67 2019-11-04T18:19:08  *** Chris_Stewart_5 has quit IRC
 68 2019-11-04T18:21:46  <sipa> aj, moneyball, jnewbery, ...: what is your opinion on making changes to the bip drafts during the review period?
 69 2019-11-04T18:22:09  <sipa> some changes may impact the summaries that have been writter (e.g. references to specific rationale footnote numbers may go out of date)
 70 2019-11-04T18:22:29  <sipa> Would it make sense to batch them up and apply them once per week, so that it's easy to see what changed?
 71 2019-11-04T18:22:48  <gmaxwell> also link to specifc revisions if there is any potential for ambiguity?
 72 2019-11-04T18:23:03  *** pinheadmz has joined ##taproot-bip-review
 73 2019-11-04T18:26:12  *** Chris_Stewart_5 has joined ##taproot-bip-review
 74 2019-11-04T18:30:53  <harding> sipa: it looks like if you create ref tags as <ref name="foo">, you'll get named refs so the links won't change if you add new footnotes or reorder them.  E.g., here's a quick test I made demonstrating: https://github.com/harding/bips/blob/2019-11-test-named-refs/bip-schnorr.mediawiki#cite_ref-suf_cma_1-0
 75 2019-11-04T18:31:18  <harding> The only other links I would expect to break would be if you renamed sub-heads.
 76 2019-11-04T18:31:37  <sipa> harding: hmm, that's not what i mean
 77 2019-11-04T18:31:59  <harding> Oh, and maybe my assertion is untrue anyway.  I don't know where the _1-0 suffix in the link above came from.
 78 2019-11-04T18:32:20  <sipa> i mean for example the curriculum for the 2nd week includes " “Rationale” sections 2, 4-14. "
 79 2019-11-04T18:32:46  <sipa> which may end up being meaningless if more rationale sections get added
 80 2019-11-04T18:33:03  <harding> Yeah.
 81 2019-11-04T18:33:28  <xoyi-> I assumed that the linearity property was what enables key aggregation (C=A+B in Taproot) and that ECDSA sigs are not linear so you can't do C=A+B. Lots of wrong assumptions right there.
 82 2019-11-04T18:33:50  <sipa> xoyi-: is it clear now?
 83 2019-11-04T18:33:51  <harding> I was thinking that instead of saying "look here" they could link to what they wanted and, if it had a descriptive name and a static URL, it wouldn't get out of date as quickly.
 84 2019-11-04T18:34:31  <xoyi-> sipa: yes, I'm still missing some pieces of the puzzle but it's much more clear. Thanks
 85 2019-11-04T18:34:49  <harding> (Instead it looks like gmaxwell's suggestion of linking to specific revisions is probably best, IMO.)
 86 2019-11-04T18:35:15  <sipa> xoyi-: key aggregation (even MuSig style) is always possible with EC keys, regardless of the signing algorithm. What Schnorr's linearity adds is that it makes it easy to construct a multiparty signing algorithm for the aggregated key
 87 2019-11-04T18:36:13  <sipa> a differrent style of key aggregation is possible that's compatible with ECDSA, but the result is still significantly more complex than what is possible with additive key aggregation + schnorr
 88 2019-11-04T18:36:31  <sipa> s/compatible/more easily compatible/
 89 2019-11-04T18:36:49  <xoyi-> I see, that clears thigns up a lot.
 90 2019-11-04T18:36:55  <xoyi-> things*
 91 2019-11-04T18:38:46  <sipa> In particular, MuSig key aggregation is non-interactive meaning that you can compute the address from just xpubs of participants for example, without communication with those participants (and more importantly, without those participants needing access to their private keys)
 92 2019-11-04T18:38:49  <luke-jr> is the meeting bot in here?
 93 2019-11-04T18:38:59  <sipa> Signing is still interactive, however.
 94 2019-11-04T18:39:04  <luke-jr> might be handy..
 95 2019-11-04T18:39:30  <gmaxwell> re ECDSA multiple party signing... its complex enough that I'm dubious about people ever managing to correctly implement the N of M case in a way that has good comprehensive security.. in theory it's not hard, but in theory plain ECDH and ECDSA signatures are _trivial_ and yet loads of things manage to screw those up.
 96 2019-11-04T18:40:02  <gmaxwell> I have never, anywhere in the world, seen even e.g. an example of the 2 of 2 case (the simplest) that doesn't have obvious timing sidechannels.
 97 2019-11-04T18:44:25  *** xoyi- has quit IRC
 98 2019-11-04T18:44:45  *** r251d has joined ##taproot-bip-review
 99 2019-11-04T18:52:44  <moneyball> sipa: I wouldn't want the review process to get in the way of making updates to the BIPs. but, as aj put in all the work to create the curriculum, I think he should have final say as to what might make it easier for him/others to update it.
100 2019-11-04T18:56:31  <gmaxwell> I don't think staging bip updates in issues is all that disruptive to edits.
101 2019-11-04T18:57:51  *** xoyi- has joined ##taproot-bip-review
102 2019-11-04T19:28:52  *** kiekedroad has joined ##taproot-bip-review
103 2019-11-04T20:17:12  *** kiekedroad has quit IRC
104 2019-11-04T20:45:32  <jb55> anyone have an IRC study group I could join? I didn't get matched
105 2019-11-04T20:48:29  *** b10c has joined ##taproot-bip-review
106 2019-11-04T20:53:52  <moneyball> jb55: i'm happy to add you to any group you'd like. have a look and let me know which time/group is best for you https://github.com/ajtowns/taproot-review/blob/master/study-groups.md
107 2019-11-04T21:09:34  <pyskl> So far group 3 only has ~half of the attendees confirmed for Thursday @ 21 UTC if that works, the more the merrier
108 2019-11-04T21:24:39  *** b10c has quit IRC
109 2019-11-04T21:27:09  *** jb55 has quit IRC
110 2019-11-04T21:37:02  *** jb55 has joined ##taproot-bip-review
111 2019-11-04T21:57:20  <luke-jr> which ironically isn't our time slot
112 2019-11-04T21:57:29  <luke-jr> and only accounts for Thurs..
113 2019-11-04T22:00:41  <pyskl> Correct, you were unable to join so I suggested moving it to an hour outside of our time slot there's no one using 21:00-22:00 on IRC as per the study groups
114 2019-11-04T22:00:45  <xoyi-> fwiw regarding my previous question about Schnorr and Taproot, apparently sipa also mentions it briefly in https://youtu.be/oTsjMz3DaLs?t=583 (that most of the things can also be done with ECDSA, albeit with a lot more work)
115 2019-11-04T22:02:28  *** pyskl has quit IRC
116 2019-11-04T22:13:40  *** diogosergio has quit IRC
117 2019-11-04T22:18:33  <harding> luke-jr: meeting bot is here and tested; see http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-03-12.56.html
118 2019-11-04T22:27:37  *** xoyi- has quit IRC
119 2019-11-04T22:28:02  *** Chris_Stewart_5 has quit IRC
120 2019-11-04T23:10:02  <aj> sipa: i don't think the review sould prevent any changes, the review should work around that. fwiw, i think the curriculum as it stands works as long as none of the headings change. but batching them would probably help avoid people looking at different versions so would probably be helpful?
121 2019-11-04T23:11:38  <aj> luke-jr: yeah, lightningbot is here and functional
122 2019-11-04T23:13:17  <sipa> aj: i think i'll just try to batch up things if they structurally change things or add/remove/reorder rationales
123 2019-11-04T23:13:26  <sipa> other things shouldn't be affected
124 2019-11-04T23:31:49  *** soju has joined ##taproot-bip-review
125 2019-11-04T23:39:44  *** Chris_Stewart_5 has joined ##taproot-bip-review
126 2019-11-04T23:51:13  *** mango has joined ##taproot-bip-review
127 2019-11-04T23:52:09  *** mango has left ##taproot-bip-review