12019-11-04T01:00:29 <takinbo> xoyi-: hey!
22019-11-04T01:08:45 *** ilan has joined ##taproot-bip-review
32019-11-04T01:30:08 *** ilan has quit IRC
42019-11-04T01:53:06 *** nick_fre_ has joined ##taproot-bip-review
52019-11-04T01:55:43 *** nick_freeman has quit IRC
62019-11-04T02:34:37 *** nick_freeman has joined ##taproot-bip-review
72019-11-04T02:37:23 *** nick_fre_ has quit IRC
82019-11-04T04:57:50 *** murch has joined ##taproot-bip-review
92019-11-04T07:34:32 *** codaelux has joined ##taproot-bip-review
102019-11-04T07:36:15 *** jonatack has joined ##taproot-bip-review
112019-11-04T07:51:39 *** xoyi- has joined ##taproot-bip-review
122019-11-04T08:20:58 *** jonatack has quit IRC
132019-11-04T08:22:37 *** jonatack has joined ##taproot-bip-review
142019-11-04T08:44:53 *** luke-jr has quit IRC
152019-11-04T08:48:24 *** luke-jr has joined ##taproot-bip-review
162019-11-04T09:10:11 *** jamieasefa has joined ##taproot-bip-review
172019-11-04T09:44:47 *** jamieasefa has quit IRC
182019-11-04T10:54:45 *** orfeas has joined ##taproot-bip-review
192019-11-04T11:34:12 *** willcl_ark has joined ##taproot-bip-review
202019-11-04T12:47:23 *** nothingmuch has joined ##taproot-bip-review
212019-11-04T13:24:59 *** jonatack has quit IRC
222019-11-04T13:53:49 *** Codaelux1 has joined ##taproot-bip-review
232019-11-04T13:54:06 *** Codaelux1 has left ##taproot-bip-review
242019-11-04T14:04:22 *** pyskl has joined ##taproot-bip-review
252019-11-04T14:33:42 *** Chris_Stewart_5 has joined ##taproot-bip-review
262019-11-04T14:36:25 *** diogosergio has joined ##taproot-bip-review
272019-11-04T15:10:30 *** dmkathayat has joined ##taproot-bip-review
282019-11-04T15:22:57 *** xoyi- has quit IRC
292019-11-04T15:25:17 *** jb55 has joined ##taproot-bip-review
302019-11-04T16:16:56 *** xoyi- has joined ##taproot-bip-review
312019-11-04T16:19:15 *** waxwing has joined ##taproot-bip-review
322019-11-04T16:22:48 *** jonatack has joined ##taproot-bip-review
332019-11-04T16:51:15 *** diogosergio has quit IRC
342019-11-04T17:03:09 *** diogosergio has joined ##taproot-bip-review
352019-11-04T17:12:50 *** diogosergio has quit IRC
362019-11-04T17:20:40 *** sosthene has joined ##taproot-bip-review
372019-11-04T17:29:08 <sosthene> Hi there, is everyone already on the Slack? :)
382019-11-04T17:29:55 <sipa> hell no.
392019-11-04T17:30:05 <sipa> :)
402019-11-04T17:30:26 <sosthene> very excited to be here!
412019-11-04T17:42:25 *** orfeas has quit IRC
422019-11-04T17:48:18 <harding> sosthene: hi!
432019-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?
442019-11-04T17:58:53 <xoyi-> (not sure if I should be asking here or in my study group, or wait for the Q&A)
452019-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
462019-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
472019-11-04T18:04:46 <xoyi-> ah got it, thanks
482019-11-04T18:04:48 <sipa> xoyi-: oh, wait, I think I'm confusing you
492019-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
502019-11-04T18:06:27 <gmaxwell> it's not tecnically required, but it would be stupid to deploy any other way.
512019-11-04T18:06:34 <gmaxwell> sipa: you can use multiply ecdsa.
522019-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
532019-11-04T18:07:01 <gmaxwell> multiparty*
542019-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
552019-11-04T18:08:18 <sipa> gmaxwell: right, that too
562019-11-04T18:10:28 <gmaxwell> sipa: even with multiple signers... with multiparty ecdsa... (ignoring the fact that multiparty ecdsa is obnoxious to implement)
572019-11-04T18:11:30 <sipa> Right, the linearity property only makes things _easier_, it's not changing things from impossible to possible.
582019-11-04T18:11:43 <gmaxwell> they _keys_ are still linear just fine...
592019-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.
602019-11-04T18:12:22 <gmaxwell> indeed.
612019-11-04T18:12:58 <gmaxwell> (well _tweaking_ needs a kind of key linearity)
622019-11-04T18:13:10 <sipa> Right, but not signature linearty.
632019-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.
642019-11-04T18:18:01 <gmaxwell> seems not, probably remembering saying it on irc.
652019-11-04T18:18:09 *** diogosergio has joined ##taproot-bip-review
662019-11-04T18:18:31 *** marcinja has joined ##taproot-bip-review
672019-11-04T18:19:08 *** Chris_Stewart_5 has quit IRC
682019-11-04T18:21:46 <sipa> aj, moneyball, jnewbery, ...: what is your opinion on making changes to the bip drafts during the review period?
692019-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)
702019-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?
712019-11-04T18:22:48 <gmaxwell> also link to specifc revisions if there is any potential for ambiguity?
722019-11-04T18:23:03 *** pinheadmz has joined ##taproot-bip-review
732019-11-04T18:26:12 *** Chris_Stewart_5 has joined ##taproot-bip-review
742019-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
752019-11-04T18:31:18 <harding> The only other links I would expect to break would be if you renamed sub-heads.
762019-11-04T18:31:37 <sipa> harding: hmm, that's not what i mean
772019-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.
782019-11-04T18:32:20 <sipa> i mean for example the curriculum for the 2nd week includes " âRationaleâ sections 2, 4-14. "
792019-11-04T18:32:46 <sipa> which may end up being meaningless if more rationale sections get added
802019-11-04T18:33:03 <harding> Yeah.
812019-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.
822019-11-04T18:33:50 <sipa> xoyi-: is it clear now?
832019-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.
842019-11-04T18:34:31 <xoyi-> sipa: yes, I'm still missing some pieces of the puzzle but it's much more clear. Thanks
852019-11-04T18:34:49 <harding> (Instead it looks like gmaxwell's suggestion of linking to specific revisions is probably best, IMO.)
862019-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
872019-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
882019-11-04T18:36:31 <sipa> s/compatible/more easily compatible/
892019-11-04T18:36:49 <xoyi-> I see, that clears thigns up a lot.
902019-11-04T18:36:55 <xoyi-> things*
912019-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)
922019-11-04T18:38:49 <luke-jr> is the meeting bot in here?
932019-11-04T18:38:59 <sipa> Signing is still interactive, however.
942019-11-04T18:39:04 <luke-jr> might be handy..
952019-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.
962019-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.
972019-11-04T18:44:25 *** xoyi- has quit IRC
982019-11-04T18:44:45 *** r251d has joined ##taproot-bip-review
992019-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.
1002019-11-04T18:56:31 <gmaxwell> I don't think staging bip updates in issues is all that disruptive to edits.
1012019-11-04T18:57:51 *** xoyi- has joined ##taproot-bip-review
1022019-11-04T19:28:52 *** kiekedroad has joined ##taproot-bip-review
1032019-11-04T20:17:12 *** kiekedroad has quit IRC
1042019-11-04T20:45:32 <jb55> anyone have an IRC study group I could join? I didn't get matched
1052019-11-04T20:48:29 *** b10c has joined ##taproot-bip-review
1062019-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
1072019-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
1082019-11-04T21:24:39 *** b10c has quit IRC
1092019-11-04T21:27:09 *** jb55 has quit IRC
1102019-11-04T21:37:02 *** jb55 has joined ##taproot-bip-review
1112019-11-04T21:57:20 <luke-jr> which ironically isn't our time slot
1122019-11-04T21:57:29 <luke-jr> and only accounts for Thurs..
1132019-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
1142019-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)
1152019-11-04T22:02:28 *** pyskl has quit IRC
1162019-11-04T22:13:40 *** diogosergio has quit IRC
1172019-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
1182019-11-04T22:27:37 *** xoyi- has quit IRC
1192019-11-04T22:28:02 *** Chris_Stewart_5 has quit IRC
1202019-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?
1212019-11-04T23:11:38 <aj> luke-jr: yeah, lightningbot is here and functional
1222019-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
1232019-11-04T23:13:26 <sipa> other things shouldn't be affected
1242019-11-04T23:31:49 *** soju has joined ##taproot-bip-review
1252019-11-04T23:39:44 *** Chris_Stewart_5 has joined ##taproot-bip-review
1262019-11-04T23:51:13 *** mango has joined ##taproot-bip-review
1272019-11-04T23:52:09 *** mango has left ##taproot-bip-review