--- Day changed Mon Nov 11 2019
00:40 -!- b10c [~Thunderbi@2001:16b8:2ecd:4a00:cfe9:d8c9:1f8:27be] has joined ##taproot-bip-review     
01:05 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]     
01:09 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review     
01:38 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 276 seconds]     
02:29 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##taproot-bip-review     
02:42 -!- yaslama [~yaslama@bzq-218-78-150.red.bezeqint.net] has quit [Remote host closed the connection]     
02:50 -!- yaslama [~yaslama@bzq-218-78-150.red.bezeqint.net] has joined ##taproot-bip-review     
03:03 -!- ZmnSCPxj [9258463b@146.88.70.59] has joined ##taproot-bip-review     
03:09 < 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).
03:09 < 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).
03:09 < 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.
03:09 < 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).
03:09 < ZmnSCPxj> This is probably only relevant to my own Nodelets proposal.
03:09 < ZmnSCPxj> I would appreciate if any mathist can confirm my thoughts.  Regards, ZmnsCPxj
03:10 -!- ZmnSCPxj [9258463b@146.88.70.59] has left ##taproot-bip-review []     
03:10 -!- ZmnSCPxj [9258463b@146.88.70.59] has joined ##taproot-bip-review     
03:11 < ZmnSCPxj> Unfortunately I am sufferring from intermittent Internet, thus I might miss any reply, I apologize.
03:11 -!- ZmnSCPxj [9258463b@146.88.70.59] has quit [Remote host closed the connection]     
03:38 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has joined ##taproot-bip-review     
03:41 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:c4e0:5e7b:afa3:c47f] has joined ##taproot-bip-review     
03:41 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:c4e0:5e7b:afa3:c47f] has quit [Client Quit]     
03:50 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has joined ##taproot-bip-review     
03:54 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has quit [Client Quit]     
03:55 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has quit [Remote host closed the connection]     
03:59 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has joined ##taproot-bip-review     
04:14 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has joined ##taproot-bip-review     
04:14 < afk11> sipa: slight fix for python schnorrsig verification https://github.com/sipa/bitcoin/pull/118
04:15 < 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?
04:32 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has quit [Quit: Sleep mode]     
04:39 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has joined ##taproot-bip-review     
05:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
05:28 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has quit [Quit: Sleep mode]     
05:35 < 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?
05:49 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has joined ##taproot-bip-review     
05:49 -!- hebasto [~hebasto@95.164.65.194] has left ##taproot-bip-review ["Leaving"]     
05:51 -!- hznc [~hznc@95.164.65.194] has joined ##taproot-bip-review     
05:52 -!- hznc [~hznc@95.164.65.194] has quit [Quit: Leaving]     
05:54 -!- hebasto [~hebasto@95.164.65.194] has joined ##taproot-bip-review     
05:56 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 246 seconds]     
05:59 -!- hznc [~hznc@95.164.65.194] has joined ##taproot-bip-review     
06:06 -!- hznc [~hznc@95.164.65.194] has quit [Remote host closed the connection]     
06:06 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##taproot-bip-review     
06:15 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 265 seconds]     
06:49 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined ##taproot-bip-review     
06:58 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review     
07:15 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has quit [Quit: Sleep mode]     
07:21 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
07:21 < 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.
07:24 -!- murch [murch@sf1.hashbang.sh] has quit [Quit: WeeChat 2.6]     
07:27 -!- Murch [murch@sf1.hashbang.sh] has joined ##taproot-bip-review     
07:29 < 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"?
07:36 < waxwing> we do call it a point.
07:37 < hebasto> from bip-schnorr "The constant G refers to the generator..."
07:39 < waxwing> yes, the generator is a point.
07:39 < waxwing> sometimes people even go wild and call it 'the generator point' :)
07:42 < hebasto> is G *the only* generator of using group?
07:51 < 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)
07:51 < waxwing> but tbh at this point i don't know what you're asking really.
07:53 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 252 seconds]     
08:02 < 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.
08:06 < sipa> hebasto: if it helps you, feel free to PR some better wording
08:07 < hebasto> sipa: thanks
08:07 < sipa> but secp256k1 is a cyclic group of prime order, so every point apart from infinity is a generator
08:07 < sipa> yet G is a specific one out of those
08:08 < hebasto> sipa: that is why "The constant G refers to the base point..." looks better
08:09 < sipa> but that sounds like there is only one possible base point
08:10 < hebasto> This is the only point used as a base point in bitcoin...
08:13 < sipa> correct
08: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"
08:29 < hebasto> https://www.secg.org/sec2-v2.pdf defines the base point G as one of EC domain parameters
08:40 -!- alon-e [uid402705@gateway/web/irccloud.com/x-cffbbdmjjfplcyzb] has quit [Quit: Connection closed for inactivity]     
08:43 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review     
08:47 -!- michaelfolkson [~textual@46.233.77.109] has joined ##taproot-bip-review     
08:47 -!- michaelfolkson [~textual@46.233.77.109] has quit [Client Quit]     
08:49 < 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
08:50 < sipa> it's just different terminology that has different origin, i suppose, and both terms are common
09:16 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]     
09:33 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review     
09:43 -!- b10c [~Thunderbi@2001:16b8:2ecd:4a00:cfe9:d8c9:1f8:27be] has quit [Ping timeout: 245 seconds]     
11:06 -!- nick_freeman [~nick_free@2001:16b8:30d4:6900:7d14:c2e1:f8a5:250c] has joined ##taproot-bip-review     
11:58 < instagibbs> elichai2, the nested musig point has been suggested as a "hidden unanimous policy within a policy"
11:58 < elichai2> hmmm
11:59 < instagibbs> Like, I could hide that our 2of2 actually has a 2-of-3 hww split for just me
11:59 < instagibbs> 1 and 2-of-3
11:59 < elichai2> 2-of-3 as in threshold?
11:59 < instagibbs> yeah
12:00 < instagibbs> ok let's just say 1 and 2of2
12:00 < elichai2> well that isn't yet a thing :) (securely)
12:00 < instagibbs> shh     
12:00 < elichai2> instagibbs: how is that different than 3-of-3?
12:00 < instagibbs> hidden policy, I don't reveal to counterparty that i have two keys
12:00 < instagibbs> opsec++ at a minimum
12:00 < elichai2> oh that you're hiding from some of the participants that there are actually *more* participants?
12:01 < instagibbs> right, Zmn refers to "sybil" issue with it
12:01 < waxwing> we heard you like multisignatures ...
12:01 < instagibbs> there's no way to tell that a participant i na musig isn't another musig...
12:02 < elichai2> right
12:02 < instagibbs> I haven't actually grokked his attack, just saying what the motivation could be
12:02 < 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
12:02 < instagibbs> yes signing is his claim
12:03 < instagibbs> ill leave that to the real-fake cryptographers in the room ;)
12:03 < elichai2> :P     
12:05 < 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
12:05 < elichai2> anyway i'd be really warry of any such scheme
12:05 < instagibbs> sounds frought enough
12:05 < instagibbs> fraught*
12:06 < instagibbs> might be good to make a note of that in the bips if that has ever been suggested..
12:07 < instagibbs> (I don't think it is from scanning)
12:07 < instagibbs> nor in the paper
12:08 < instagibbs> so, it still sounds safe in the "I am actually running a 3of3 scheme as one key"
12:09 < instagibbs> but not as a split party one
12:13 < nickler> another straightforward application is having your lightning wallet be a multisig transparently
12:13 < 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".
12:14 < sanket1729> I know fresh is always good, but is it necessary here?
12:14 < nickler> real-or-random came up with the idea of using additively homomorphic commitments which I meant to write up last week...
12:14 < sanket1729> I guess you can prevent 2 same scripts from having the taproot external key
12:18 -!- pyskl [~pyskell@194.36.111.51] has joined ##taproot-bip-review     
12:20 < 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
12:22 < sanket1729> I guess H is a bad idea. Maybe something fixed H + r*G, but the r does not need to change.
12:23 < sanket1729> nevermind, it is the same. Everyone will eventually realize it
12:23 < instagibbs> "BIP16" makes an introduction in bip-tapscript. I presume this is vestigial due to previous p2sh support?
12:24 < instagibbs> "If the input is invalid due to BIP16, BIP141, or bip-taproot, fail."
12:24 < nickler> "when you do a key spend you need to show the internal key" <- I meant script
12:25 < sipa> instagibbs: yes, i think that can be removed
12:25 < instagibbs> also, I find the BIP141 reference difficult. What parts of BIP141 is it referring to?
12:25 < sipa> it's not incorrect of course
12:25 < sipa> instagibbs: all of it?
12:26 < sipa> BIP141 specifies the segwit consensus rules
12:26 < instagibbs> well tons of it has no bearing on it
12:26 < sipa> sure
12:26 < sipa> not the P2WSH/P2WPKH specifics
12:26 < instagibbs> I guess I'd have to re-reat bip-taproot, see what's not already defined, and what's only covered in bip141
12:27 < instagibbs> this section already presumes a bip-taproot spend
12:27 < 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."
12:27 < sipa> *invalid
12:27 < instagibbs> ah ok, weight limits at least, couldn't think of an example :P
12:27 < instagibbs> sigops
12:27 < instagibbs> well no
12:27 < sipa> sigops are actually gone
12:27 < instagibbs> right
12:28 < sipa> and maybe it's worth pointing out in bip-taproot that key-path spends do not count towards the sigop limit
12:28 < instagibbs> so for me as a reader, it's like easter egg hunt to figure out what that means
12:28 < instagibbs> (I'll keep reading)
12:28 < 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!"
12:28 < instagibbs> fair enough
12:29 < sipa> it's not trying to hide any information, just pointing out that other rules don't magically disappear
12:29 < instagibbs> ok, in that sense bip16 is just the most "flagrant" for me, and can optionally be removed
12:29 < instagibbs> since there is no overlap
12:30 < sipa> agreed
12:31 < sipa> plz PR
12:46 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has quit [Remote host closed the connection]     
12:50 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds]     
12:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
13:18 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review     
13:38 -!- pyskl [~pyskell@194.36.111.51] has quit [Quit: Leaving]     
14:28 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
14:50 -!- nick_freeman [~nick_free@2001:16b8:30d4:6900:7d14:c2e1:f8a5:250c] has left ##taproot-bip-review []     
16:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]     
17:20 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 240 seconds]     
17:25 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
18:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
23:42 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##taproot-bip-review