1 2019-11-11T00:02:45  *** elichai2 has joined ##taproot-bip-review
  2 2019-11-11T00:11:48  *** michaelfolkson has quit IRC
  3 2019-11-11T00:29:20  *** michaelfolkson has joined ##taproot-bip-review
  4 2019-11-11T00:41:28  *** michaelfolkson has quit IRC
  5 2019-11-11T01:00:20  *** michaelfolkson has joined ##taproot-bip-review
  6 2019-11-11T01:02:59  *** michaelfolkson has quit IRC
  7 2019-11-11T01:08:50  *** michaelfolkson has joined ##taproot-bip-review
  8 2019-11-11T01:15:59  *** michaelfolkson has quit IRC
  9 2019-11-11T02:01:25  *** HighOnBtc has joined ##taproot-bip-review
 10 2019-11-11T03:08:21  *** HighOnBtc has quit IRC
 11 2019-11-11T03:11:14  *** andytoshi has quit IRC
 12 2019-11-11T03:28:22  *** pinheadmz has joined ##taproot-bip-review
 13 2019-11-11T07:40:27  *** codaelux has quit IRC
 14 2019-11-11T08:40:02  *** b10c has joined ##taproot-bip-review
 15 2019-11-11T09:05:54  *** jonatack has quit IRC
 16 2019-11-11T09:09:50  *** jonatack has joined ##taproot-bip-review
 17 2019-11-11T09:38:47  *** jonatack has quit IRC
 18 2019-11-11T10:29:20  *** jonatack has joined ##taproot-bip-review
 19 2019-11-11T10:42:05  *** yaslama has quit IRC
 20 2019-11-11T10:50:12  *** yaslama has joined ##taproot-bip-review
 21 2019-11-11T11:03:34  *** ZmnSCPxj has joined ##taproot-bip-review
 22 2019-11-11T11:09:04  <ZmnSCPxj> Good morning all. I believe MuSig(MuSig(A, B), C) is unsafe if there is the possibility that B == C (conversely, that A == C).
 23 2019-11-11T11:09:10  <ZmnSCPxj> This is because the commitment to R of MuSig(A, B) must be computed after both A and B have revealed their Rs before they can be added to create the commitment to R of MuSig(A,B).
 24 2019-11-11T11:09:16  <ZmnSCPxj> Thus, B (and C if secretly B == C) knows the R of A before C has to reveal its own commitment to its own R, and C can now cancel the R of A, leaving only the R of B.
 25 2019-11-11T11:09:21  <ZmnSCPxj> Thus, it seems to me that any nested MuSig(MuSig(A, B), C) would require, if there is the possibility of any kind of Sybil, to be "flattened" out to MuSig(A, B, C).
 26 2019-11-11T11:09:25  <ZmnSCPxj> This is probably only relevant to my own Nodelets proposal.
 27 2019-11-11T11:09:29  <ZmnSCPxj> I would appreciate if any mathist can confirm my thoughts.  Regards, ZmnsCPxj
 28 2019-11-11T11:10:33  *** ZmnSCPxj has left ##taproot-bip-review
 29 2019-11-11T11:10:44  *** ZmnSCPxj has joined ##taproot-bip-review
 30 2019-11-11T11:11:22  <ZmnSCPxj> Unfortunately I am sufferring from intermittent Internet, thus I might miss any reply, I apologize.
 31 2019-11-11T11:11:28  *** ZmnSCPxj has quit IRC
 32 2019-11-11T11:38:53  *** orfeas has joined ##taproot-bip-review
 33 2019-11-11T11:41:19  *** michaelfolkson has joined ##taproot-bip-review
 34 2019-11-11T11:41:34  *** michaelfolkson has quit IRC
 35 2019-11-11T11:50:41  *** michaelfolkson has joined ##taproot-bip-review
 36 2019-11-11T11:54:40  *** michaelfolkson has quit IRC
 37 2019-11-11T11:55:47  *** orfeas has quit IRC
 38 2019-11-11T11:59:23  *** orfeas has joined ##taproot-bip-review
 39 2019-11-11T12:14:13  *** michaelfolkson has joined ##taproot-bip-review
 40 2019-11-11T12:14:18  <afk11> sipa: slight fix for python schnorrsig verification https://github.com/sipa/bitcoin/pull/118
 41 2019-11-11T12:15:46  <elichai2> ZmnSCPxj: generally I don't think the security proofs behind Musig look into nested Musigs. it's a bit weird, why would you want a nested Musig?
 42 2019-11-11T12:32:13  *** michaelfolkson has quit IRC
 43 2019-11-11T12:39:23  *** michaelfolkson has joined ##taproot-bip-review
 44 2019-11-11T13:09:34  *** Chris_Stewart_5 has joined ##taproot-bip-review
 45 2019-11-11T13:28:21  *** michaelfolkson has quit IRC
 46 2019-11-11T13:35:16  <hebasto> sipa: from bip-schnorr "The constant G refers to the generator..." IMHO, *generator* - is a group algebra notion. It is not strictly correct to say "generator has x and y coordinates". I'd prefer "The constant G refers to the secp256k1 base point..." Or did I miss the relevant earlier discussion?
 47 2019-11-11T13:49:16  *** michaelfolkson has joined ##taproot-bip-review
 48 2019-11-11T13:49:33  *** hebasto has left ##taproot-bip-review
 49 2019-11-11T13:51:34  *** hznc has joined ##taproot-bip-review
 50 2019-11-11T13:52:40  *** hznc has quit IRC
 51 2019-11-11T13:54:11  *** hebasto has joined ##taproot-bip-review
 52 2019-11-11T13:56:36  *** jonatack has quit IRC
 53 2019-11-11T13:59:28  *** hznc has joined ##taproot-bip-review
 54 2019-11-11T14:06:22  *** hznc has quit IRC
 55 2019-11-11T14:06:54  *** jonatack has joined ##taproot-bip-review
 56 2019-11-11T14:15:36  *** jonatack has quit IRC
 57 2019-11-11T14:49:40  *** stacie has joined ##taproot-bip-review
 58 2019-11-11T14:58:06  *** HighOnBtc has joined ##taproot-bip-review
 59 2019-11-11T15:15:30  *** michaelfolkson has quit IRC
 60 2019-11-11T15:21:03  *** stacie has quit IRC
 61 2019-11-11T15:21:17  <waxwing> hebasto, care to explain? in the specific context of an elliptic curve, the generator is exactly a point on the curve, and so does have x and y coordinates. the group we're using is a set of elliptic curve points with the operation of point addition.
 62 2019-11-11T15:24:10  *** murch has quit IRC
 63 2019-11-11T15:27:24  *** Murch has joined ##taproot-bip-review
 64 2019-11-11T15:29:42  <hebasto> waxwing: thanks. I knew these facts ;) Let me reword: coordinates are properties of a point on EC. Talking about point G, why do not call it "point"?
 65 2019-11-11T15:36:40  <waxwing> we do call it a point.
 66 2019-11-11T15:37:47  <hebasto> from bip-schnorr "The constant G refers to the generator..."
 67 2019-11-11T15:39:05  <waxwing> yes, the generator is a point.
 68 2019-11-11T15:39:17  <waxwing> sometimes people even go wild and call it 'the generator point' :)
 69 2019-11-11T15:42:46  <hebasto> is G *the only* generator of using group?
 70 2019-11-11T15:51:03  <waxwing> it's a prime order group; you could choose any other point in the group and have the same group generated. apart from point at \infty. (ie identity element)
 71 2019-11-11T15:51:15  <waxwing> but tbh at this point i don't know what you're asking really.
 72 2019-11-11T15:53:00  *** HighOnBtc has quit IRC
 73 2019-11-11T16:02:29  <hebasto> when we are talking about coordinates of G, we should call it "base point G"; when we're talking about group properties, e.g., order of element etc, we could call it "generator". IMO, it could make things simpler to reasoning about them.
 74 2019-11-11T16:06:14  <sipa> hebasto: if it helps you, feel free to PR some better wording
 75 2019-11-11T16:07:21  <hebasto> sipa: thanks
 76 2019-11-11T16:07:21  <sipa> but secp256k1 is a cyclic group of prime order, so every point apart from infinity is a generator
 77 2019-11-11T16:07:43  <sipa> yet G is a specific one out of those
 78 2019-11-11T16:08:46  <hebasto> sipa: that is why "The constant G refers to the base point..." looks better
 79 2019-11-11T16:09:43  <sipa> but that sounds like there is only one possible base point
 80 2019-11-11T16:10:31  <hebasto> This is the only point used as a base point in bitcoin...
 81 2019-11-11T16:13:16  <sipa> correct
 82 2019-11-11T16:22:22  <sipa> i think the term base point refers to the DLP actually; for example you can say "finding the private key of corresponding to public key P requires finding the DL lf P w.r.t. base point G"
 83 2019-11-11T16:29:11  <hebasto> https://www.secg.org/sec2-v2.pdf defines the base point G as one of EC domain parameters
 84 2019-11-11T16:40:02  *** alon-e has quit IRC
 85 2019-11-11T16:43:30  *** jonatack has joined ##taproot-bip-review
 86 2019-11-11T16:47:16  *** michaelfolkson has joined ##taproot-bip-review
 87 2019-11-11T16:47:33  *** michaelfolkson has quit IRC
 88 2019-11-11T16:49:27  <elichai2> I don't get the discussion. if you and I decide on a group we need to agree on the properties of the group. one of those properties is *a generator* otherwise we can't *generate* elements on/in the group
 89 2019-11-11T16:50:26  <sipa> it's just different terminology that has different origin, i suppose, and both terms are common
 90 2019-11-11T17:16:02  *** jonatack has quit IRC
 91 2019-11-11T17:33:27  *** jonatack has joined ##taproot-bip-review
 92 2019-11-11T17:43:13  *** b10c has quit IRC
 93 2019-11-11T19:06:30  *** nick_freeman has joined ##taproot-bip-review
 94 2019-11-11T19:58:05  <instagibbs> elichai2, the nested musig point has been suggested as a "hidden unanimous policy within a policy"
 95 2019-11-11T19:58:59  <elichai2> hmmm
 96 2019-11-11T19:59:17  <instagibbs> Like, I could hide that our 2of2 actually has a 2-of-3 hww split for just me
 97 2019-11-11T19:59:29  <instagibbs> 1 and 2-of-3
 98 2019-11-11T19:59:49  <elichai2> 2-of-3 as in threshold?
 99 2019-11-11T19:59:58  <instagibbs> yeah
100 2019-11-11T20:00:10  <instagibbs> ok let's just say 1 and 2of2
101 2019-11-11T20:00:17  <elichai2> well that isn't yet a thing :) (securely)
102 2019-11-11T20:00:20  <instagibbs> shh
103 2019-11-11T20:00:24  <elichai2> instagibbs: how is that different than 3-of-3?
104 2019-11-11T20:00:43  <instagibbs> hidden policy, I don't reveal to counterparty that i have two keys
105 2019-11-11T20:00:50  <instagibbs> opsec++ at a minimum
106 2019-11-11T20:00:56  <elichai2> oh that you're hiding from some of the participants that there are actually *more* participants?
107 2019-11-11T20:01:09  <instagibbs> right, Zmn refers to "sybil" issue with it
108 2019-11-11T20:01:46  <waxwing> we heard you like multisignatures ...
109 2019-11-11T20:01:49  <instagibbs> there's no way to tell that a participant i na musig isn't another musig...
110 2019-11-11T20:02:02  <elichai2> right
111 2019-11-11T20:02:24  <instagibbs> I haven't actually grokked his attack, just saying what the motivation could be
112 2019-11-11T20:02:46  <elichai2> I'm trying to think if there's a problem with it. I don't think there's a problem in the Key generation phase. about the signing phase hmmm
113 2019-11-11T20:02:55  <instagibbs> yes signing is his claim
114 2019-11-11T20:03:35  <instagibbs> ill leave that to the real-fake cryptographers in the room ;)
115 2019-11-11T20:03:44  <elichai2> :P
116 2019-11-11T20:05:17  <elichai2> well you'll either need to have everyones commitments before starting to reveal any R, *or* have a secure channel between the subgroup, commit, reveal and then one of the subgroup participates in the bigger group
117 2019-11-11T20:05:29  <elichai2> anyway i'd be really warry of any such scheme
118 2019-11-11T20:05:54  <instagibbs> sounds frought enough
119 2019-11-11T20:05:58  <instagibbs> fraught*
120 2019-11-11T20:06:23  <instagibbs> might be good to make a note of that in the bips if that has ever been suggested..
121 2019-11-11T20:07:12  <instagibbs> (I don't think it is from scanning)
122 2019-11-11T20:07:37  <instagibbs> nor in the paper
123 2019-11-11T20:08:48  <instagibbs> so, it still sounds safe in the "I am actually running a 3of3 scheme as one key"
124 2019-11-11T20:09:13  <instagibbs> but not as a split party one
125 2019-11-11T20:13:32  <nickler> another straightforward application is having your lightning wallet be a multisig transparently
126 2019-11-11T20:13:58  <sanket1729> In bip taproot -> "In order to avoid leaking the information that key path spending is not possible it is recommended to pick a *fresh* integer r .... use H +r*G".
127 2019-11-11T20:14:11  <sanket1729> I know fresh is always good, but is it necessary here?
128 2019-11-11T20:14:17  <nickler> real-or-random came up with the idea of using additively homomorphic commitments which I meant to write up last week...
129 2019-11-11T20:14:49  <sanket1729> I guess you can prevent 2 same scripts from having the taproot external key
130 2019-11-11T20:18:56  *** pyskl has joined ##taproot-bip-review
131 2019-11-11T20:20:12  <nickler> sanket1729: no, when you do a key spend you need to show the internal key. If you're just using H you're unnecessarily showing the world that a key path spend was impossible
132 2019-11-11T20:22:55  <sanket1729> I guess H is a bad idea. Maybe something fixed H + r*G, but the r does not need to change.
133 2019-11-11T20:23:08  <sanket1729> nevermind, it is the same. Everyone will eventually realize it
134 2019-11-11T20:23:47  <instagibbs> "BIP16" makes an introduction in bip-tapscript. I presume this is vestigial due to previous p2sh support?
135 2019-11-11T20:24:02  <instagibbs> "If the input is invalid due to BIP16, BIP141, or bip-taproot, fail."
136 2019-11-11T20:24:12  <nickler> "when you do a key spend you need to show the internal key" <- I meant script
137 2019-11-11T20:25:36  <sipa> instagibbs: yes, i think that can be removed
138 2019-11-11T20:25:38  <instagibbs> also, I find the BIP141 reference difficult. What parts of BIP141 is it referring to?
139 2019-11-11T20:25:48  <sipa> it's not incorrect of course
140 2019-11-11T20:25:49  <sipa> instagibbs: all of it?
141 2019-11-11T20:26:02  <sipa> BIP141 specifies the segwit consensus rules
142 2019-11-11T20:26:02  <instagibbs> well tons of it has no bearing on it
143 2019-11-11T20:26:11  <sipa> sure
144 2019-11-11T20:26:22  <sipa> not the P2WSH/P2WPKH specifics
145 2019-11-11T20:26:49  <instagibbs> I guess I'd have to re-reat bip-taproot, see what's not already defined, and what's only covered in bip141
146 2019-11-11T20:27:05  <instagibbs> this section already presumes a bip-taproot spend
147 2019-11-11T20:27:23  <sipa> maybe it should say instead "If the spend is valid because of any other consensus rule (including BIP 141), the spend is invalid; doing otherwise would make this not a softfork."
148 2019-11-11T20:27:30  <sipa> *invalid
149 2019-11-11T20:27:34  <instagibbs> ah ok, weight limits at least, couldn't think of an example :P
150 2019-11-11T20:27:41  <instagibbs> sigops
151 2019-11-11T20:27:45  <instagibbs> well no
152 2019-11-11T20:27:49  <sipa> sigops are actually gone
153 2019-11-11T20:27:58  <instagibbs> right
154 2019-11-11T20:28:07  <sipa> and maybe it's worth pointing out in bip-taproot that key-path spends do not count towards the sigop limit
155 2019-11-11T20:28:14  <instagibbs> so for me as a reader, it's like easter egg hunt to figure out what that means
156 2019-11-11T20:28:19  <instagibbs> (I'll keep reading)
157 2019-11-11T20:28:45  <sipa> instagibbs: i think the point is that it doesn't mean anything; you could read that sentence as "note that this is a softfork, so all other consensus rules apply too!"
158 2019-11-11T20:28:54  <instagibbs> fair enough
159 2019-11-11T20:29:07  <sipa> it's not trying to hide any information, just pointing out that other rules don't magically disappear
160 2019-11-11T20:29:44  <instagibbs> ok, in that sense bip16 is just the most "flagrant" for me, and can optionally be removed
161 2019-11-11T20:29:49  <instagibbs> since there is no overlap
162 2019-11-11T20:30:55  <sipa> agreed
163 2019-11-11T20:31:04  <sipa> plz PR
164 2019-11-11T20:46:29  *** orfeas has quit IRC
165 2019-11-11T20:50:18  *** jeremyrubin has quit IRC
166 2019-11-11T20:54:24  *** Chris_Stewart_5 has quit IRC
167 2019-11-11T21:18:37  *** HighOnBtc has joined ##taproot-bip-review
168 2019-11-11T21:38:08  *** pyskl has quit IRC
169 2019-11-11T22:28:21  *** Chris_Stewart_5 has joined ##taproot-bip-review
170 2019-11-11T22:50:11  *** nick_freeman has left ##taproot-bip-review