1 2019-11-07T00:34:08  *** pyskell has joined ##taproot-bip-review
  2 2019-11-07T00:43:53  *** Chris_Stewart_5 has joined ##taproot-bip-review
  3 2019-11-07T00:45:10  *** soju has quit IRC
  4 2019-11-07T00:50:43  *** michaelfolkson has joined ##taproot-bip-review
  5 2019-11-07T00:59:30  *** evoskuil[m] has joined ##taproot-bip-review
  6 2019-11-07T00:59:44  *** evoskuil has joined ##taproot-bip-review
  7 2019-11-07T01:01:31  *** andytoshi has joined ##taproot-bip-review
  8 2019-11-07T01:05:40  *** pinheadmz has joined ##taproot-bip-review
  9 2019-11-07T01:33:36  <moneyball> Reminder of upcoming Q&A session in 30 minutes
 10 2019-11-07T01:51:39  *** Tibo has joined ##taproot-bip-review
 11 2019-11-07T01:57:09  *** soju has joined ##taproot-bip-review
 12 2019-11-07T01:59:49  <aj> dammit, missed the 30 second reminder
 13 2019-11-07T01:59:57  <sipa> by 19 seconds
 14 2019-11-07T02:00:03  <moneyball> whoops
 15 2019-11-07T02:00:12  <aj> #startmeeting
 16 2019-11-07T02:00:12  <lightningbot> Meeting started Thu Nov  7 02:00:12 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
 17 2019-11-07T02:00:12  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 18 2019-11-07T02:00:44  *** gmaxwell has left ##taproot-bip-review
 19 2019-11-07T02:00:44  *** fanquake has joined ##taproot-bip-review
 20 2019-11-07T02:00:45  *** gmaxwell has joined ##taproot-bip-review
 21 2019-11-07T02:00:53  <aj> hi round 2 folks!
 22 2019-11-07T02:00:57  <andytoshi> hiya
 23 2019-11-07T02:00:59  <moneyball> hi
 24 2019-11-07T02:01:01  <Tibo> hi
 25 2019-11-07T02:01:01  <fanquake> hi
 26 2019-11-07T02:01:03  <sipa> hi
 27 2019-11-07T02:01:04  <soju> hi
 28 2019-11-07T02:01:06  <gmaxwell> I was gonna ping everyone in the room but there are a lot of people here.
 29 2019-11-07T02:01:37  <sipa> Log from the previous Q&A session: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.log.html
 30 2019-11-07T02:02:06  <gmaxwell> I move to approve the minutes of the last meeting. All in favor?
 31 2019-11-07T02:02:29  <moneyball> aye
 32 2019-11-07T02:02:43  <gmaxwell> Motion carries.
 33 2019-11-07T02:02:45  <sipa> All 60 minutes?
 34 2019-11-07T02:02:51  <moneyball> We have a bunch of experts here on Taproot so please ask any questions you might have
 35 2019-11-07T02:04:24  <gmaxwell> Especialy all those questions which you were too embarassed to ask in front of the europeans.
 36 2019-11-07T02:04:50  <sipa> I'll be here the whole hour, so if anything comes up, feel free to ask any time.
 37 2019-11-07T02:05:02  <Tibo> A small question on requiring to commit to an unspendable script path instead of having no script path. From the doc it is not clear to me if that is a "should" (like it's nice to do it especially in some specific key aggregation scheme) or a "must" (like really do it otherwise you're dead)
 38 2019-11-07T02:05:10  *** Chris_Stewart_5 has quit IRC
 39 2019-11-07T02:05:22  <sipa> Tibo: that's a good question
 40 2019-11-07T02:05:53  <sipa> there are many situations in which it's perfectly fine to just use a public key directly as an output point.
 41 2019-11-07T02:05:56  <andytoshi> my feeling is that it's a "should" ... there are many cases where it's safe not to do this
 42 2019-11-07T02:06:11  <andytoshi> in particular if there is only one party
 43 2019-11-07T02:06:22  <andytoshi> or if all parties are using musig and checking the derivation
 44 2019-11-07T02:06:53  <sipa> But at the same time, not doing it may be dangerous in situations where it isn't all that obvious, so it should be common practice to just do it.
 45 2019-11-07T02:06:53  <Tibo> ok thanks for clarifying!
 46 2019-11-07T02:07:01  <gmaxwell> If your key is truly random then it is impossible to prove to a third party that there isn't some other script.  Now, in many (most?) cases it's none of anyone elses business-- and especially not the business of a third party to the key creation-- if there is some other script...
 47 2019-11-07T02:07:41  <gmaxwell> It's not really that different from the fact that unless your key is in a HSM you cannot prove that you didn't give someone else a copy of the private key.
 48 2019-11-07T02:08:21  <andytoshi> i think having the ability to prove this is useful ... i mean, it's harmless to -have- the ability
 49 2019-11-07T02:08:21  <aj> if your key was generated by a HSM, you might want the HSM to prove to you there's no hidden script path in there though
 50 2019-11-07T02:08:31  <sipa> I think it's fair to say that it's always fine to use a pubkey directly when there is only one signer.
 51 2019-11-07T02:08:34  <andytoshi> oh very good point aj
 52 2019-11-07T02:08:36  <gmaxwell> aj: right.
 53 2019-11-07T02:09:30  <Tibo> I see interesting.
 54 2019-11-07T02:09:32  <gmaxwell> aj: my point was just that it's very rare that existing bitcoin users today bother proving to anyone that a key wasn't copied.  "There might be a hidden tapscript" is a similar risk.
 55 2019-11-07T02:10:24  <aj> gmaxwell: yep
 56 2019-11-07T02:10:26  <gmaxwell> Sipa's point is that its better to do it by default because its essentially free, and in the rare case you do want that proof you can generate it
 57 2019-11-07T02:10:49  <gmaxwell> vs if you thought you wouldn't need to prove it, but then later did, you won't be able to.
 58 2019-11-07T02:12:01  <sipa> One specific example where it is actually dangerous, and not just a "you can't prove" is when you're doing naive key aggregation (just summing up pubkeys), even together with certified keys (which without taproot would be secure), there is now a combined taproot+aggregation rogue key attack where one party offset his key by exactly as much as necessary to later steal the funds using a script
 59 2019-11-07T02:12:05  <sipa> that just includes the attacker
 60 2019-11-07T02:12:36  <sipa> But that still involves multiple parties.
 61 2019-11-07T02:13:46  <gmaxwell> oh thats a nice attack-- he could even prove knowledge of the discrete log.
 62 2019-11-07T02:16:31  <Tibo> So I think I'm a bit confused with this proof thing. If I understand (and I feel like I don't) the proof would be to show someone that you have P such that Q = P + hash(P) * G. But couldn't P itself be an already tweaked key?
 63 2019-11-07T02:16:52  <sipa> Tibo: it certainly could be, but that doesn't matter
 64 2019-11-07T02:17:29  <Tibo> Ah yeah because you couldn't spend it anyway?
 65 2019-11-07T02:17:36  <sipa> The taproot consensus spending rules do not let you take advantage of P being tweaked somehow (you can only do the "hey! look! Q is not actually a pubkey, but it commits to a script!" thing once)
 66 2019-11-07T02:17:38  <gmaxwell> Tibo: that taproot construction itself isn't recursive, there can be exactly one top level tweak.
 67 2019-11-07T02:18:00  <Tibo> Yes I see thanks
 68 2019-11-07T02:18:35  <gmaxwell> Tibo: also if you have some fancy key generation scheme you should be _always_ able to do that final tweak as essentially a post processing step.
 69 2019-11-07T02:19:02  <gmaxwell> Then either have one of your signers increment his private key by hash(P), or add an addition dummy signer with private key hash(P).
 70 2019-11-07T02:20:01  <aj> Tibo: the two-level tweaking thing might be something coloured coins end up using https://github.com/rgb-org/spec/issues/61
 71 2019-11-07T02:21:12  <Tibo> gmaxwell thanks
 72 2019-11-07T02:21:16  <Tibo> @aj
 73 2019-11-07T02:21:27  <gmaxwell> aj: for a number of years Blockstream's liquid has used a tweaked key to commit to the outputs that should get paid on the sidechain. So yeah there are other applications that might be tweaking P for other reasons.
 74 2019-11-07T02:21:53  <Tibo> aj thanks for the link will check that (heard about rgb but didn't look into it that much yet)
 75 2019-11-07T02:22:06  <arik_> even with a non-recursive construction though, I struggle to see how just for the top-level key it's possible to prove that it is _not_ tweaked. If it is tweaked, I know the resulting private key and can always only disclose that one.
 76 2019-11-07T02:22:54  <arik_> but I also agree it shouldn't really be anyone else's business
 77 2019-11-07T02:24:06  <sipa> arik_: you can't prove it's not tweaked
 78 2019-11-07T02:24:19  <sipa> unless it's generated in some other way that is in conflict with tweaking
 79 2019-11-07T02:24:28  <sipa> and the best way to do that... is to tweak it :)
 80 2019-11-07T02:24:44  <arik_> I could tweak it by an OP_RETURN and reveal that
 81 2019-11-07T02:24:45  *** ZmnSCPxj has joined ##taproot-bip-review
 82 2019-11-07T02:25:20  <gmaxwell> arik_: Or tweak it with the key itself, then your forgery challenge turns into a loop, and forging it requires finding a collision to the hash function.
 83 2019-11-07T02:25:31  <arik_> yes, that's better
 84 2019-11-07T02:25:40  <arik_> because I was gonna say that I can always tweak it twice, and choose which tweak to reveal
 85 2019-11-07T02:25:55  *** michaelfolkson has quit IRC
 86 2019-11-07T02:25:57  <gmaxwell> arik_: thats why the 'tweaking' process includes the pubkey in the hash.
 87 2019-11-07T02:26:18  <arik_> oops
 88 2019-11-07T02:26:20  <gmaxwell> So you can't do something like pick two scripts, add them, and then choose which to reveal.
 89 2019-11-07T02:26:42  <gmaxwell> FWIW, the earliest descriptions of 'pay to contract' had that vulnerablity.
 90 2019-11-07T02:26:48  <aj> arik_: (tweaking it twice, and being able to reveal either the left or the right path is kind of what g'root does :)
 91 2019-11-07T02:29:19  *** lightlike has quit IRC
 92 2019-11-07T02:29:26  <sipa> kind of, but let's not go into that
 93 2019-11-07T02:31:19  <gmaxwell> It would be useful someplace (probably not in the BIPs) to enumerate out all the effective limits on taproot/tapscript, including ones inherited from other parts of the protocol... and indicate which are standardness vs consensus.
 94 2019-11-07T02:31:37  <gmaxwell> As I was ignorantly thinking the maximum stack element limit didn't apply anymore last night.
 95 2019-11-07T02:31:49  *** nick_fre_ has joined ##taproot-bip-review
 96 2019-11-07T02:31:53  <sipa> gmaxwell: that one is even explicitly spelled out in the bip, i just forgot about it :)
 97 2019-11-07T02:32:02  <gmaxwell> (and a lot of limits don't apply anymore)
 98 2019-11-07T02:32:18  <gmaxwell> The reason for that one is stuff like quadratic OP_ROLL cost?
 99 2019-11-07T02:33:38  *** isho has joined ##taproot-bip-review
100 2019-11-07T02:33:44  <sipa> yeah
101 2019-11-07T02:34:09  <gmaxwell> Makes sense.
102 2019-11-07T02:34:22  <sipa> and there are certainly ways to avoid the quadratic cost, but they're nontrivial and can have high constant factors
103 2019-11-07T02:34:53  *** nick_freeman has quit IRC
104 2019-11-07T02:36:47  <sipa> (an OP_SUCCESS could lift that limit, btw)
105 2019-11-07T02:38:05  <aj> one thing that was briefly discussed on slack was security proofs for taproot; do we know of flaws in apoelstra's paper, or what other properties might be worth proving?
106 2019-11-07T02:38:57  <andytoshi> i believe my paper is correct but there is disagreement on whether the security model makes sense
107 2019-11-07T02:39:45  <andytoshi> specifically i claim that you can't spend a taproot output without signing with the key, or revealing the originally-embedded script and signing with that
108 2019-11-07T02:40:03  <andytoshi> but real_or_random had some argument that this didn't cover something
109 2019-11-07T02:40:16  <andytoshi> that i didn't fully grok
110 2019-11-07T02:41:26  <sipa> the attacker gets to know the script, right?
111 2019-11-07T02:41:53  <andytoshi> oh, right, in my proof this is the case
112 2019-11-07T02:41:59  <andytoshi> i don't address privacy at all, in any form
113 2019-11-07T02:42:12  <andytoshi> which is one problem with it
114 2019-11-07T02:42:21  <sipa> i think one thing real_or_random pointed out is for example: what if the private key of the internal key is embedded in cleartext in the script?
115 2019-11-07T02:42:59  <andytoshi> oh right! i implicitly assume this is not the case
116 2019-11-07T02:43:00  <sipa> which isn't interesting, but by modelling the script as an abstract thing you can't consider cases like that
117 2019-11-07T02:43:03  <andytoshi> yep
118 2019-11-07T02:43:42  <sipa> a more concrete abstraction that's probably much closer to what we want is something where you model script as a set of conjunctions of public keys
119 2019-11-07T02:44:45  <sipa> and give the attacker an oracle that can sign for whatever (key path, or any of the "scripts" involved), and he wins if he can produce a signature for a key/script he didn't ask the oracle for
120 2019-11-07T02:45:16  <andytoshi> i don't really like this, it fails to capture any nontrivial use of script
121 2019-11-07T02:45:35  <sipa> i agree - it's not complete
122 2019-11-07T02:45:43  <andytoshi> you could extend it to cover hash preimages and timelocks, a la miniscript, then as soon as you use OP_ROLL the security proof doesn't apply
123 2019-11-07T02:46:02  <sipa> but it does capture things like: what if the internal key gets reused inside one of the scripts?
124 2019-11-07T02:46:05  <gmaxwell> this seems way too application specific.
125 2019-11-07T02:46:30  <gmaxwell> It's not like we expect to have a security proof for the hashtree that says it's kosher with timelocks. :P
126 2019-11-07T02:46:57  <andytoshi> well, there's an intuition that you can't reveal the wrong script, or spend without satisfying the script or producing a signature
127 2019-11-07T02:47:00  <aj> 14m left; do feel free to interrupt with questions if you still have them
128 2019-11-07T02:47:01  <andytoshi> that would be worthwhile to capture formally
129 2019-11-07T02:47:44  <gmaxwell> I think a proof should just attack taproot as a computationally sound commitment scheme, like you might prove the security of a pedersen commitment.
130 2019-11-07T02:47:59  <sipa> gmaxwell: andytoshi has that
131 2019-11-07T02:48:02  <andytoshi> for that, my proof is sufficient
132 2019-11-07T02:48:12  <andytoshi> though it's pretty noisy because it tries to do more
133 2019-11-07T02:48:18  <sipa> but i think that's a fairly low-level property
134 2019-11-07T02:48:31  <arik_> Andrew, would you mind sharing a link to your paper in the chat?
135 2019-11-07T02:48:45  <arik_> thanks!
136 2019-11-07T02:48:59  <aj> arik_: https://github.com/apoelstra/taproot
137 2019-11-07T02:49:01  <gmaxwell> it's unclear to me that you can achieve a higher level without rapidly running into absurdity like "op_roll invalidates the proof".
138 2019-11-07T02:49:08  <arik_> thanks, aj!
139 2019-11-07T02:50:06  <aj> sanket shared a pdf he'd written up of some security properties to prove on slack; but it was a raw pdf not a link
140 2019-11-07T02:50:46  <sipa> another interesting property is showing that if the internal key is random, a taproot output is indistinguishable from any other
141 2019-11-07T02:51:00  <sipa> (i don't think anyone doubts that's the case, but a proof would still be nice)
142 2019-11-07T02:51:15  *** Tibo has quit IRC
143 2019-11-07T02:51:46  <gmaxwell> that should be trivial to proof, almost a definition, of H() is a random oracle.
144 2019-11-07T02:51:53  <gmaxwell> s/of/if/
145 2019-11-07T02:51:57  <sipa> yes.
146 2019-11-07T02:54:21  <gmaxwell> like P is a uniform point from group of size N. t=H(P||whatever) is a uniform scalar of size N (by defintion of random oracle). tG is a uniform point (bijection).  Q+tG is a uniform point (addition is complete). or something along those lines.
147 2019-11-07T02:56:08  <arik_> yeah, I imagine as long as the field and group orders are mentioned it's trivial
148 2019-11-07T02:57:19  <arik_> pardon my ignorance, but have we had previous proofs of security for proposals of a similar scope, like for p2sh or segwit?
149 2019-11-07T02:57:26  <sipa> nope.
150 2019-11-07T02:57:33  <sipa> nor script.
151 2019-11-07T02:57:37  *** HighOnBtc has quit IRC
152 2019-11-07T02:58:08  <andytoshi> i think with segwit the only property that needed proving was that everything was committed to
153 2019-11-07T02:58:32  <gmaxwell> andytoshi: no, that there weren't 'hash emulation' would have been useful to prove.
154 2019-11-07T02:58:59  <gmaxwell> e.g. that post stripping that two different messages couldnt have the same inputs to the hash, unless the messages differed only in the intended ways.
155 2019-11-07T02:59:20  <andytoshi> ah. yes.
156 2019-11-07T02:59:23  <gmaxwell> hm I guess thats what you meant.
157 2019-11-07T02:59:28  <andytoshi> technically yes
158 2019-11-07T02:59:31  <andytoshi> but morally no
159 2019-11-07T02:59:35  <andytoshi> i meant something dumber :P
160 2019-11-07T03:00:05  <andytoshi> along the lines of "moving data from one part of the tree to another doesn't remove it from the tree"
161 2019-11-07T03:00:50  <aj> okay, that's the hour!
162 2019-11-07T03:00:54  <aj> #endmeeting
163 2019-11-07T03:00:54  <lightningbot> Meeting ended Thu Nov  7 03:00:54 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
164 2019-11-07T03:00:54  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-07-02.00.html
165 2019-11-07T03:00:54  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-07-02.00.txt
166 2019-11-07T03:00:54  <lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-07-02.00.log.html
167 2019-11-07T03:07:54  *** yas has quit IRC
168 2019-11-07T03:09:39  *** andytoshi has quit IRC
169 2019-11-07T03:11:00  *** andytoshi has joined ##taproot-bip-review
170 2019-11-07T03:11:00  *** andytoshi has joined ##taproot-bip-review
171 2019-11-07T03:39:07  *** gmaxwell has left ##taproot-bip-review
172 2019-11-07T04:31:17  *** yaslama has quit IRC
173 2019-11-07T04:50:35  *** isho has quit IRC
174 2019-11-07T05:03:22  *** soju__ has joined ##taproot-bip-review
175 2019-11-07T05:05:27  *** yaslama has joined ##taproot-bip-review
176 2019-11-07T05:07:48  *** soju__ has quit IRC
177 2019-11-07T05:14:33  *** eltneg has joined ##taproot-bip-review
178 2019-11-07T05:29:31  *** isho has joined ##taproot-bip-review
179 2019-11-07T06:01:58  *** kabaum has quit IRC
180 2019-11-07T06:59:26  *** kabaum has joined ##taproot-bip-review
181 2019-11-07T07:04:21  *** soju__ has joined ##taproot-bip-review
182 2019-11-07T07:28:32  *** evoskuil has quit IRC
183 2019-11-07T07:33:44  *** eltneg has quit IRC
184 2019-11-07T07:56:38  *** soju__ has quit IRC
185 2019-11-07T08:00:59  *** jonatack has quit IRC
186 2019-11-07T08:20:58  *** soju__ has joined ##taproot-bip-review
187 2019-11-07T08:48:22  *** john_ has quit IRC
188 2019-11-07T08:51:54  *** jonatack has joined ##taproot-bip-review
189 2019-11-07T08:52:25  *** soju__ has quit IRC
190 2019-11-07T08:54:25  *** b10c has joined ##taproot-bip-review
191 2019-11-07T08:59:14  *** kabaum has quit IRC
192 2019-11-07T09:01:53  *** soju__ has joined ##taproot-bip-review
193 2019-11-07T09:02:14  *** soju__ has quit IRC
194 2019-11-07T09:53:29  *** kabaum has joined ##taproot-bip-review
195 2019-11-07T10:45:50  *** ZmnSCPxj_ has joined ##taproot-bip-review
196 2019-11-07T10:46:02  *** ZmnSCPxj has quit IRC
197 2019-11-07T10:54:01  *** orfeas has joined ##taproot-bip-review
198 2019-11-07T10:59:10  <orfeas> sorry, I've lost the name of the group 7 bip review channel. was it ##taproot-bip-review-group-7 again?
199 2019-11-07T11:00:22  <evoskuil[m]> ##bitcoin-taproot-sg7
200 2019-11-07T11:07:17  <orfeas> thanks!
201 2019-11-07T11:22:20  *** ZmnSCPxj_ has quit IRC
202 2019-11-07T11:23:04  *** ZmnSCPxj_ has joined ##taproot-bip-review
203 2019-11-07T11:30:27  *** ZmnSCPxj_ has quit IRC
204 2019-11-07T11:31:16  *** ZmnSCPxj_ has joined ##taproot-bip-review
205 2019-11-07T11:34:22  *** andytoshi has quit IRC
206 2019-11-07T11:57:00  *** kabaum has quit IRC
207 2019-11-07T12:10:36  *** kabaum has joined ##taproot-bip-review
208 2019-11-07T12:11:39  *** ZmnSCPxj_ has quit IRC
209 2019-11-07T12:12:03  *** ZmnSCPxj_ has joined ##taproot-bip-review
210 2019-11-07T12:14:29  *** ZmnSCPxj_ has quit IRC
211 2019-11-07T12:16:37  *** Chris_Stewart_5 has joined ##taproot-bip-review
212 2019-11-07T12:30:37  *** Chris_Stewart_5 has quit IRC
213 2019-11-07T12:35:11  *** justinmoon has joined ##taproot-bip-review
214 2019-11-07T12:36:28  <justinmoon> Question: why is musig signing always interactive?
215 2019-11-07T12:40:00  *** ZmnSCPxj_ has joined ##taproot-bip-review
216 2019-11-07T12:52:10  <aj> justinmoon: because you need to share a unique set of R values per Pubkey,Message pair
217 2019-11-07T12:53:14  *** r251d has quit IRC
218 2019-11-07T12:53:33  *** jonatack has quit IRC
219 2019-11-07T12:53:36  *** r251d has joined ##taproot-bip-review
220 2019-11-07T12:55:27  *** jonatack has joined ##taproot-bip-review
221 2019-11-07T13:02:20  *** stacie has joined ##taproot-bip-review
222 2019-11-07T13:04:15  *** Chris_Stewart_5 has joined ##taproot-bip-review
223 2019-11-07T13:12:16  <justinmoon> Pubkey is aggregate pubkey of all signers?
224 2019-11-07T13:13:38  *** jonatack has quit IRC
225 2019-11-07T13:14:04  *** jonatack has joined ##taproot-bip-review
226 2019-11-07T13:23:09  <aj> justinmoon: yeah... actually that phrasing is probably not quite right; you need different R values to avoid reusing your nonce with two different H(R,P,m) values which would allow other sto figure out your private key
227 2019-11-07T13:28:33  <justinmoon> aj: Thanks. So if I wanted to sign a 3/5 musig where all keys are controlled by different parties and stored in bank vaults with no internet, the different signers could commit to a set of R values while online, and then each signer could enter their offline bank vault and sign?
228 2019-11-07T13:31:43  <aj> justinmoon: the R values need to be generated as securely as the private keys are stored
229 2019-11-07T13:31:51  <aj> justinmoon: (since reusing them reveals the private key)
230 2019-11-07T13:32:46  <aj> justinmoon: i think you can generate a bunch of R values on one visit to the vault, and then use those R values for a later transaction on a later visit to the vault, but getting it right requires some storage for the hardware wallet in the vault
231 2019-11-07T13:34:44  <justinmoon> aj: You'd need to tell your cosigners about these pre-generated R values as well?
232 2019-11-07T13:35:01  <aj> https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/musig/musig.md might be understandable for threshold sigs -- they require interactive setup and storage for the key setup as well, which n-of-n musig doesn't
233 2019-11-07T13:36:00  <aj> justinmoon: yeah, you need to generate   s_me = r_me + H(R_me + R_you + R_them, P_me + P_you + P_them, msg)*p_me -- so you can't sign until you know all the R's
234 2019-11-07T13:36:37  <aj> justinmoon: and you need to do a two-phase commit to tell everyone the R's or else you become vulnerable to wagner's attack or so
235 2019-11-07T13:50:07  <justinmoon> aj: Thanks. In summary, you can accomplish "offline signing" if offline wallet and online wallet each store a bit more state.
236 2019-11-07T13:50:19  <justinmoon> aj: And deterministic-k schemes don't work because signature aggregation implies you could solve for private keys?
237 2019-11-07T13:56:34  <aj> justinmoon: if you do deterministic-k but your cosigner doesn't do deterministic-k, then when you combine the two they can solve for a private key. if you both share zk-proofs that you did determinist-k then everything's good -- you can make the k = Hash(private_key, counter) and prove that everyone used the same counter, and only ever sign when the new counter is greater than the last counter you
238 2019-11-07T13:56:35  <aj> signed for
239 2019-11-07T13:57:18  *** michaelfolkson has joined ##taproot-bip-review
240 2019-11-07T13:58:27  <aj> you would then generate K=k*G and the zkp in advance / batched, share them all, and to do a signature just collect K_100 from enough signers, and take the proofs into the vaults
241 2019-11-07T13:59:05  <aj> (i think, i tend to forget necessary details when describing this stuff off the top of my head, so take it with a grain of salt)
242 2019-11-07T14:07:51  *** jonatack has quit IRC
243 2019-11-07T14:10:14  <instagibbs> how often are QAs?
244 2019-11-07T14:13:31  <aj> two a week
245 2019-11-07T14:14:42  <aj> instagibbs: fyi, planning on including a link to your liquid-tapscript-case-study ipynb in the week-2 notes
246 2019-11-07T14:14:51  <instagibbs> kk
247 2019-11-07T14:27:44  *** Chris_Stewart_5 has quit IRC
248 2019-11-07T14:29:50  *** Chris_Stewart_5 has joined ##taproot-bip-review
249 2019-11-07T15:01:13  *** michaelfolkson has quit IRC
250 2019-11-07T15:03:26  *** michaelfolkson has joined ##taproot-bip-review
251 2019-11-07T15:23:55  *** michaelfolkson has quit IRC
252 2019-11-07T15:29:57  *** kabaum has quit IRC
253 2019-11-07T15:47:00  <murch> Please consider cross-posting any interesting questions to Bitcoin Stackexchange. :)
254 2019-11-07T15:47:30  <murch> e.g. justinmoon's question above why MuSig signing is always interactive would be a good candidate.
255 2019-11-07T15:47:56  <justinmoon> murch: i'll post that
256 2019-11-07T15:48:04  <murch> Thank ye.
257 2019-11-07T16:11:41  *** stacie has quit IRC
258 2019-11-07T16:21:35  *** stacie has joined ##taproot-bip-review
259 2019-11-07T16:21:56  *** soju__ has joined ##taproot-bip-review
260 2019-11-07T16:26:53  *** jonatack has joined ##taproot-bip-review
261 2019-11-07T16:29:10  *** kabaum has joined ##taproot-bip-review
262 2019-11-07T16:40:59  <justinmoon> murch: https://bitcoin.stackexchange.com/questions/91534/musig-interactivity
263 2019-11-07T16:42:20  <sipa> justinmoon: fwiw, we're working on a paper on deterministic nonces in musig
264 2019-11-07T16:51:35  *** HighOnBtc has joined ##taproot-bip-review
265 2019-11-07T17:05:01  <instagibbs> justinmoon, would also be nice to know exactly "what can go wrong" in a cold setup with musig
266 2019-11-07T17:05:51  <justinmoon> instagibbs: Yes. Musig footguns.
267 2019-11-07T17:06:07  *** HighOnBtc has quit IRC
268 2019-11-07T17:11:30  *** kabaum has quit IRC
269 2019-11-07T17:20:44  *** michaelfolkson has joined ##taproot-bip-review
270 2019-11-07T17:42:14  *** andytoshi has joined ##taproot-bip-review
271 2019-11-07T17:55:14  *** michaelfolkson has quit IRC
272 2019-11-07T17:59:54  *** Chris_Stewart_5 has quit IRC
273 2019-11-07T18:00:02  *** orfeas has quit IRC
274 2019-11-07T18:05:02  *** michaelfolkson has joined ##taproot-bip-review
275 2019-11-07T18:12:32  *** michaelfolkson has quit IRC
276 2019-11-07T18:15:09  <murch> justinmoon: Thanks. :)
277 2019-11-07T18:31:24  *** Chris_Stewart_5 has joined ##taproot-bip-review
278 2019-11-07T18:36:57  *** jenseven has quit IRC
279 2019-11-07T18:44:54  *** soju__ has quit IRC
280 2019-11-07T18:45:03  *** Chris_Stewart_5 has quit IRC
281 2019-11-07T18:51:15  *** Chris_Stewart_5 has joined ##taproot-bip-review
282 2019-11-07T19:02:26  <nickler> justinmoon: fwiw I discussed some of the consideration at breaking bitcoin this year, slide 19. https://nickler.ninja/slides/2019-breaking.pdf
283 2019-11-07T19:03:22  <justinmoon> nickler: Thanks!
284 2019-11-07T19:12:07  *** stacie has quit IRC
285 2019-11-07T19:19:37  *** stacie has joined ##taproot-bip-review
286 2019-11-07T19:38:52  <instagibbs> nickler, "non-musig key agg" would follow the same signing rounds, right?
287 2019-11-07T19:47:12  *** stacie has quit IRC
288 2019-11-07T19:47:50  *** stacie has joined ##taproot-bip-review
289 2019-11-07T20:03:59  *** soju__ has joined ##taproot-bip-review
290 2019-11-07T20:08:13  *** soju__ has quit IRC
291 2019-11-07T20:12:03  <nickler> instagibbs: if you mean DL-based and without the zkp mentioned above then yes afaik
292 2019-11-07T20:12:31  <instagibbs> yes, meaning your slides thanks
293 2019-11-07T20:12:31  <nickler> I posted an answer on stackexchange
294 2019-11-07T20:12:45  <nickler> instagibbs: ah, yeah
295 2019-11-07T20:14:41  <instagibbs> 2 roundtrips to vault is still so painful :'(
296 2019-11-07T20:17:32  <sipa> nickler: very nice answer
297 2019-11-07T20:17:34  <nickler> you can make it only 1 roundtrip to one of your vaults
298 2019-11-07T20:18:45  <instagibbs> i mean 2 visits to vault, unless you mean only 1 visit
299 2019-11-07T20:20:27  <nickler> I mean 1 visit. Let's say you have 3 keys, VaultA, VaultB, VaultC. You've already pre-shared nonce commitments, you go to VaultA get the nonce, go to VaultB get the nonce, go to VaultC get the nonce, and return with a partial signature using the sum of the nonces
300 2019-11-07T20:20:35  <nickler> so you only go to VaultC once
301 2019-11-07T20:21:47  <instagibbs> Ok amortized, because N parallel sessions
302 2019-11-07T20:23:34  <nickler> yeah, only works once, but also makes sense for example when you use musig in lightning
303 2019-11-07T20:24:03  <instagibbs> I mean LN is super hot, not a big deal
304 2019-11-07T20:24:17  <instagibbs> Latency issues aside
305 2019-11-07T20:25:46  <devrandom> you can't reuse nonces for different messages, right?
306 2019-11-07T20:26:18  *** kabaum has joined ##taproot-bip-review
307 2019-11-07T20:26:20  <sipa> devrandom: no
308 2019-11-07T20:26:52  <sipa> any known (sufficiently simple) relation between nonces used in distinct (partial) signatures leaks the private key
309 2019-11-07T20:27:27  <devrandom> so I'm not sure what pre-sharing buys you (from a UX point of view), given that you need to regenerate the nonces for every signature you make
310 2019-11-07T20:27:45  <sipa> you can pregenerate a million nonces
311 2019-11-07T20:28:04  <sipa> as long as you make sure not to ever use the same one twice
312 2019-11-07T20:28:21  <sipa> (i don't recommend that, to be clear, but in certain cases that is safe)
313 2019-11-07T20:28:46  <devrandom> ah, right, you can do a batch of them
314 2019-11-07T20:30:44  <devrandom> can the nonces be deterministically generated from the private keys and a counter, to reduce storage requirements?
315 2019-11-07T20:31:22  <sipa> yes, but
316 2019-11-07T20:31:32  <sipa> you must still guarantee they're never reused
317 2019-11-07T20:31:47  <sipa> in particular, you cannot deterministically generate them from the private key and the message like in single sigs
318 2019-11-07T20:32:11  <devrandom> ah, of course, if you batch them in advance you don't know the message, so then you need to keep track of the message to allocated nonce
319 2019-11-07T20:32:15  <sipa> because then you'd like your private key by participating in two signing attempts for the same message
320 2019-11-07T20:32:24  <sipa> s/like/leak/
321 2019-11-07T20:34:21  *** andytoshi has quit IRC
322 2019-11-07T20:55:27  *** mattleon has joined ##taproot-bip-review
323 2019-11-07T20:59:12  <devrandom> the meeting invite for study group 3 refers to this channel.  is that right, or is there a specific channel for our group?
324 2019-11-07T20:59:24  <mattleon> also here for group 3
325 2019-11-07T20:59:39  <mattleon> though there was an email that mentioned another channel, I'll dig it up
326 2019-11-07T21:00:09  <sipa> i think the idea is just that you'd use this channel to coordinate
327 2019-11-07T21:00:24  <pyskell> devrandom, mattleon that's correct
328 2019-11-07T21:00:34  <devrandom> I see it now - #bitcoin-taproot-sg3
329 2019-11-07T21:00:50  <pyskell> Can we use the logging bot in other channels then sipa?
330 2019-11-07T21:01:40  <pyskell> Maybe aj or moneyball know?
331 2019-11-07T21:04:03  <luke-jr> meeting bot seems more useful
332 2019-11-07T21:04:59  <pyskell> #help
333 2019-11-07T21:40:02  *** Chris_Stewart_5 has quit IRC
334 2019-11-07T21:41:46  *** ZmnSCPxj_ has quit IRC
335 2019-11-07T21:53:47  *** andytoshi has joined ##taproot-bip-review
336 2019-11-07T21:53:47  *** andytoshi has joined ##taproot-bip-review
337 2019-11-07T22:09:23  *** mattleon has quit IRC
338 2019-11-07T22:16:41  *** soju__ has joined ##taproot-bip-review
339 2019-11-07T22:23:25  *** soju__ has quit IRC
340 2019-11-07T22:35:43  *** soju__ has joined ##taproot-bip-review
341 2019-11-07T22:35:57  *** ZmnSCPxj_ has joined ##taproot-bip-review
342 2019-11-07T22:36:03  *** b10c has quit IRC
343 2019-11-07T22:40:16  *** soju__ has quit IRC
344 2019-11-07T22:46:28  *** stacie has joined ##taproot-bip-review
345 2019-11-07T22:49:17  *** stacie has quit IRC
346 2019-11-07T22:52:11  <aj> pyskell: i can add lightningbot to other channels, but if you want meetbot logging for a 1h meeting, just doing it here would be much easier i think
347 2019-11-07T22:52:46  *** pinheadmz has quit IRC
348 2019-11-07T22:54:44  *** ZmnSCPxj_ has quit IRC
349 2019-11-07T23:00:17  *** pglazman has quit IRC
350 2019-11-07T23:02:05  *** soju__ has joined ##taproot-bip-review
351 2019-11-07T23:04:05  *** pglazman has joined ##taproot-bip-review
352 2019-11-07T23:35:51  *** pglazman has quit IRC
353 2019-11-07T23:42:55  *** pglazman has joined ##taproot-bip-review