12019-11-11T00:02:45  *** elichai2 has joined ##taproot-bip-review
  22019-11-11T00:11:48  *** michaelfolkson has quit IRC
  32019-11-11T00:29:20  *** michaelfolkson has joined ##taproot-bip-review
  42019-11-11T00:41:28  *** michaelfolkson has quit IRC
  52019-11-11T01:00:20  *** michaelfolkson has joined ##taproot-bip-review
  62019-11-11T01:02:59  *** michaelfolkson has quit IRC
  72019-11-11T01:08:50  *** michaelfolkson has joined ##taproot-bip-review
  82019-11-11T01:15:59  *** michaelfolkson has quit IRC
  92019-11-11T02:01:25  *** HighOnBtc has joined ##taproot-bip-review
 102019-11-11T03:08:21  *** HighOnBtc has quit IRC
 112019-11-11T03:11:14  *** andytoshi has quit IRC
 122019-11-11T03:28:22  *** pinheadmz has joined ##taproot-bip-review
 132019-11-11T07:40:27  *** codaelux has quit IRC
 142019-11-11T08:40:02  *** b10c has joined ##taproot-bip-review
 152019-11-11T09:05:54  *** jonatack has quit IRC
 162019-11-11T09:09:50  *** jonatack has joined ##taproot-bip-review
 172019-11-11T09:38:47  *** jonatack has quit IRC
 182019-11-11T10:29:20  *** jonatack has joined ##taproot-bip-review
 192019-11-11T10:42:05  *** yaslama has quit IRC
 202019-11-11T10:50:12  *** yaslama has joined ##taproot-bip-review
 212019-11-11T11:03:34  *** ZmnSCPxj has joined ##taproot-bip-review
 222019-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).
 232019-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).
 242019-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.
 252019-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).
 262019-11-11T11:09:25  <ZmnSCPxj> This is probably only relevant to my own Nodelets proposal.
 272019-11-11T11:09:29  <ZmnSCPxj> I would appreciate if any mathist can confirm my thoughts.  Regards, ZmnsCPxj
 282019-11-11T11:10:33  *** ZmnSCPxj has left ##taproot-bip-review
 292019-11-11T11:10:44  *** ZmnSCPxj has joined ##taproot-bip-review
 302019-11-11T11:11:22  <ZmnSCPxj> Unfortunately I am sufferring from intermittent Internet, thus I might miss any reply, I apologize.
 312019-11-11T11:11:28  *** ZmnSCPxj has quit IRC
 322019-11-11T11:38:53  *** orfeas has joined ##taproot-bip-review
 332019-11-11T11:41:19  *** michaelfolkson has joined ##taproot-bip-review
 342019-11-11T11:41:34  *** michaelfolkson has quit IRC
 352019-11-11T11:50:41  *** michaelfolkson has joined ##taproot-bip-review
 362019-11-11T11:54:40  *** michaelfolkson has quit IRC
 372019-11-11T11:55:47  *** orfeas has quit IRC
 382019-11-11T11:59:23  *** orfeas has joined ##taproot-bip-review
 392019-11-11T12:14:13  *** michaelfolkson has joined ##taproot-bip-review
 402019-11-11T12:14:18  <afk11> sipa: slight fix for python schnorrsig verification https://github.com/sipa/bitcoin/pull/118
 412019-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?
 422019-11-11T12:32:13  *** michaelfolkson has quit IRC
 432019-11-11T12:39:23  *** michaelfolkson has joined ##taproot-bip-review
 442019-11-11T13:09:34  *** Chris_Stewart_5 has joined ##taproot-bip-review
 452019-11-11T13:28:21  *** michaelfolkson has quit IRC
 462019-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?
 472019-11-11T13:49:16  *** michaelfolkson has joined ##taproot-bip-review
 482019-11-11T13:49:33  *** hebasto has left ##taproot-bip-review
 492019-11-11T13:51:34  *** hznc has joined ##taproot-bip-review
 502019-11-11T13:52:40  *** hznc has quit IRC
 512019-11-11T13:54:11  *** hebasto has joined ##taproot-bip-review
 522019-11-11T13:56:36  *** jonatack has quit IRC
 532019-11-11T13:59:28  *** hznc has joined ##taproot-bip-review
 542019-11-11T14:06:22  *** hznc has quit IRC
 552019-11-11T14:06:54  *** jonatack has joined ##taproot-bip-review
 562019-11-11T14:15:36  *** jonatack has quit IRC
 572019-11-11T14:49:40  *** stacie has joined ##taproot-bip-review
 582019-11-11T14:58:06  *** HighOnBtc has joined ##taproot-bip-review
 592019-11-11T15:15:30  *** michaelfolkson has quit IRC
 602019-11-11T15:21:03  *** stacie has quit IRC
 612019-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.
 622019-11-11T15:24:10  *** murch has quit IRC
 632019-11-11T15:27:24  *** Murch has joined ##taproot-bip-review
 642019-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"?
 652019-11-11T15:36:40  <waxwing> we do call it a point.
 662019-11-11T15:37:47  <hebasto> from bip-schnorr "The constant G refers to the generator..."
 672019-11-11T15:39:05  <waxwing> yes, the generator is a point.
 682019-11-11T15:39:17  <waxwing> sometimes people even go wild and call it 'the generator point' :)
 692019-11-11T15:42:46  <hebasto> is G *the only* generator of using group?
 702019-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)
 712019-11-11T15:51:15  <waxwing> but tbh at this point i don't know what you're asking really.
 722019-11-11T15:53:00  *** HighOnBtc has quit IRC
 732019-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.
 742019-11-11T16:06:14  <sipa> hebasto: if it helps you, feel free to PR some better wording
 752019-11-11T16:07:21  <hebasto> sipa: thanks
 762019-11-11T16:07:21  <sipa> but secp256k1 is a cyclic group of prime order, so every point apart from infinity is a generator
 772019-11-11T16:07:43  <sipa> yet G is a specific one out of those
 782019-11-11T16:08:46  <hebasto> sipa: that is why "The constant G refers to the base point..." looks better
 792019-11-11T16:09:43  <sipa> but that sounds like there is only one possible base point
 802019-11-11T16:10:31  <hebasto> This is the only point used as a base point in bitcoin...
 812019-11-11T16:13:16  <sipa> correct
 822019-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"
 832019-11-11T16:29:11  <hebasto> https://www.secg.org/sec2-v2.pdf defines the base point G as one of EC domain parameters
 842019-11-11T16:40:02  *** alon-e has quit IRC
 852019-11-11T16:43:30  *** jonatack has joined ##taproot-bip-review
 862019-11-11T16:47:16  *** michaelfolkson has joined ##taproot-bip-review
 872019-11-11T16:47:33  *** michaelfolkson has quit IRC
 882019-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
 892019-11-11T16:50:26  <sipa> it's just different terminology that has different origin, i suppose, and both terms are common
 902019-11-11T17:16:02  *** jonatack has quit IRC
 912019-11-11T17:33:27  *** jonatack has joined ##taproot-bip-review
 922019-11-11T17:43:13  *** b10c has quit IRC
 932019-11-11T19:06:30  *** nick_freeman has joined ##taproot-bip-review
 942019-11-11T19:58:05  <instagibbs> elichai2, the nested musig point has been suggested as a "hidden unanimous policy within a policy"
 952019-11-11T19:58:59  <elichai2> hmmm
 962019-11-11T19:59:17  <instagibbs> Like, I could hide that our 2of2 actually has a 2-of-3 hww split for just me
 972019-11-11T19:59:29  <instagibbs> 1 and 2-of-3
 982019-11-11T19:59:49  <elichai2> 2-of-3 as in threshold?
 992019-11-11T19:59:58  <instagibbs> yeah
1002019-11-11T20:00:10  <instagibbs> ok let's just say 1 and 2of2
1012019-11-11T20:00:17  <elichai2> well that isn't yet a thing :) (securely)
1022019-11-11T20:00:20  <instagibbs> shh
1032019-11-11T20:00:24  <elichai2> instagibbs: how is that different than 3-of-3?
1042019-11-11T20:00:43  <instagibbs> hidden policy, I don't reveal to counterparty that i have two keys
1052019-11-11T20:00:50  <instagibbs> opsec++ at a minimum
1062019-11-11T20:00:56  <elichai2> oh that you're hiding from some of the participants that there are actually *more* participants?
1072019-11-11T20:01:09  <instagibbs> right, Zmn refers to "sybil" issue with it
1082019-11-11T20:01:46  <waxwing> we heard you like multisignatures ...
1092019-11-11T20:01:49  <instagibbs> there's no way to tell that a participant i na musig isn't another musig...
1102019-11-11T20:02:02  <elichai2> right
1112019-11-11T20:02:24  <instagibbs> I haven't actually grokked his attack, just saying what the motivation could be
1122019-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
1132019-11-11T20:02:55  <instagibbs> yes signing is his claim
1142019-11-11T20:03:35  <instagibbs> ill leave that to the real-fake cryptographers in the room ;)
1152019-11-11T20:03:44  <elichai2> :P
1162019-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
1172019-11-11T20:05:29  <elichai2> anyway i'd be really warry of any such scheme
1182019-11-11T20:05:54  <instagibbs> sounds frought enough
1192019-11-11T20:05:58  <instagibbs> fraught*
1202019-11-11T20:06:23  <instagibbs> might be good to make a note of that in the bips if that has ever been suggested..
1212019-11-11T20:07:12  <instagibbs> (I don't think it is from scanning)
1222019-11-11T20:07:37  <instagibbs> nor in the paper
1232019-11-11T20:08:48  <instagibbs> so, it still sounds safe in the "I am actually running a 3of3 scheme as one key"
1242019-11-11T20:09:13  <instagibbs> but not as a split party one
1252019-11-11T20:13:32  <nickler> another straightforward application is having your lightning wallet be a multisig transparently
1262019-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".
1272019-11-11T20:14:11  <sanket1729> I know fresh is always good, but is it necessary here?
1282019-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...
1292019-11-11T20:14:49  <sanket1729> I guess you can prevent 2 same scripts from having the taproot external key
1302019-11-11T20:18:56  *** pyskl has joined ##taproot-bip-review
1312019-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
1322019-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.
1332019-11-11T20:23:08  <sanket1729> nevermind, it is the same. Everyone will eventually realize it
1342019-11-11T20:23:47  <instagibbs> "BIP16" makes an introduction in bip-tapscript. I presume this is vestigial due to previous p2sh support?
1352019-11-11T20:24:02  <instagibbs> "If the input is invalid due to BIP16, BIP141, or bip-taproot, fail."
1362019-11-11T20:24:12  <nickler> "when you do a key spend you need to show the internal key" <- I meant script
1372019-11-11T20:25:36  <sipa> instagibbs: yes, i think that can be removed
1382019-11-11T20:25:38  <instagibbs> also, I find the BIP141 reference difficult. What parts of BIP141 is it referring to?
1392019-11-11T20:25:48  <sipa> it's not incorrect of course
1402019-11-11T20:25:49  <sipa> instagibbs: all of it?
1412019-11-11T20:26:02  <sipa> BIP141 specifies the segwit consensus rules
1422019-11-11T20:26:02  <instagibbs> well tons of it has no bearing on it
1432019-11-11T20:26:11  <sipa> sure
1442019-11-11T20:26:22  <sipa> not the P2WSH/P2WPKH specifics
1452019-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
1462019-11-11T20:27:05  <instagibbs> this section already presumes a bip-taproot spend
1472019-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."
1482019-11-11T20:27:30  <sipa> *invalid
1492019-11-11T20:27:34  <instagibbs> ah ok, weight limits at least, couldn't think of an example :P
1502019-11-11T20:27:41  <instagibbs> sigops
1512019-11-11T20:27:45  <instagibbs> well no
1522019-11-11T20:27:49  <sipa> sigops are actually gone
1532019-11-11T20:27:58  <instagibbs> right
1542019-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
1552019-11-11T20:28:14  <instagibbs> so for me as a reader, it's like easter egg hunt to figure out what that means
1562019-11-11T20:28:19  <instagibbs> (I'll keep reading)
1572019-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!"
1582019-11-11T20:28:54  <instagibbs> fair enough
1592019-11-11T20:29:07  <sipa> it's not trying to hide any information, just pointing out that other rules don't magically disappear
1602019-11-11T20:29:44  <instagibbs> ok, in that sense bip16 is just the most "flagrant" for me, and can optionally be removed
1612019-11-11T20:29:49  <instagibbs> since there is no overlap
1622019-11-11T20:30:55  <sipa> agreed
1632019-11-11T20:31:04  <sipa> plz PR
1642019-11-11T20:46:29  *** orfeas has quit IRC
1652019-11-11T20:50:18  *** jeremyrubin has quit IRC
1662019-11-11T20:54:24  *** Chris_Stewart_5 has quit IRC
1672019-11-11T21:18:37  *** HighOnBtc has joined ##taproot-bip-review
1682019-11-11T21:38:08  *** pyskl has quit IRC
1692019-11-11T22:28:21  *** Chris_Stewart_5 has joined ##taproot-bip-review
1702019-11-11T22:50:11  *** nick_freeman has left ##taproot-bip-review