12019-11-07T00:34:08  *** pyskell has joined ##taproot-bip-review
  22019-11-07T00:43:53  *** Chris_Stewart_5 has joined ##taproot-bip-review
  32019-11-07T00:45:10  *** soju has quit IRC
  42019-11-07T00:50:43  *** michaelfolkson has joined ##taproot-bip-review
  52019-11-07T00:59:30  *** evoskuil[m] has joined ##taproot-bip-review
  62019-11-07T00:59:44  *** evoskuil has joined ##taproot-bip-review
  72019-11-07T01:01:31  *** andytoshi has joined ##taproot-bip-review
  82019-11-07T01:05:40  *** pinheadmz has joined ##taproot-bip-review
  92019-11-07T01:33:36  <moneyball> Reminder of upcoming Q&A session in 30 minutes
 102019-11-07T01:51:39  *** Tibo has joined ##taproot-bip-review
 112019-11-07T01:57:09  *** soju has joined ##taproot-bip-review
 122019-11-07T01:59:49  <aj> dammit, missed the 30 second reminder
 132019-11-07T01:59:57  <sipa> by 19 seconds
 142019-11-07T02:00:03  <moneyball> whoops
 152019-11-07T02:00:12  <aj> #startmeeting
 162019-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.
 172019-11-07T02:00:12  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 182019-11-07T02:00:44  *** gmaxwell has left ##taproot-bip-review
 192019-11-07T02:00:44  *** fanquake has joined ##taproot-bip-review
 202019-11-07T02:00:45  *** gmaxwell has joined ##taproot-bip-review
 212019-11-07T02:00:53  <aj> hi round 2 folks!
 222019-11-07T02:00:57  <andytoshi> hiya
 232019-11-07T02:00:59  <moneyball> hi
 242019-11-07T02:01:01  <Tibo> hi
 252019-11-07T02:01:01  <fanquake> hi
 262019-11-07T02:01:03  <sipa> hi
 272019-11-07T02:01:04  <soju> hi
 282019-11-07T02:01:06  <gmaxwell> I was gonna ping everyone in the room but there are a lot of people here.
 292019-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
 302019-11-07T02:02:06  <gmaxwell> I move to approve the minutes of the last meeting. All in favor?
 312019-11-07T02:02:29  <moneyball> aye
 322019-11-07T02:02:43  <gmaxwell> Motion carries.
 332019-11-07T02:02:45  <sipa> All 60 minutes?
 342019-11-07T02:02:51  <moneyball> We have a bunch of experts here on Taproot so please ask any questions you might have
 352019-11-07T02:04:24  <gmaxwell> Especialy all those questions which you were too embarassed to ask in front of the europeans.
 362019-11-07T02:04:50  <sipa> I'll be here the whole hour, so if anything comes up, feel free to ask any time.
 372019-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)
 382019-11-07T02:05:10  *** Chris_Stewart_5 has quit IRC
 392019-11-07T02:05:22  <sipa> Tibo: that's a good question
 402019-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.
 412019-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
 422019-11-07T02:06:11  <andytoshi> in particular if there is only one party
 432019-11-07T02:06:22  <andytoshi> or if all parties are using musig and checking the derivation
 442019-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.
 452019-11-07T02:06:53  <Tibo> ok thanks for clarifying!
 462019-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...
 472019-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.
 482019-11-07T02:08:21  <andytoshi> i think having the ability to prove this is useful ... i mean, it's harmless to -have- the ability
 492019-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
 502019-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.
 512019-11-07T02:08:34  <andytoshi> oh very good point aj
 522019-11-07T02:08:36  <gmaxwell> aj: right.
 532019-11-07T02:09:30  <Tibo> I see interesting.
 542019-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.
 552019-11-07T02:10:24  <aj> gmaxwell: yep
 562019-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
 572019-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.
 582019-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
 592019-11-07T02:12:05  <sipa> that just includes the attacker
 602019-11-07T02:12:36  <sipa> But that still involves multiple parties.
 612019-11-07T02:13:46  <gmaxwell> oh thats a nice attack-- he could even prove knowledge of the discrete log.
 622019-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?
 632019-11-07T02:16:52  <sipa> Tibo: it certainly could be, but that doesn't matter
 642019-11-07T02:17:29  <Tibo> Ah yeah because you couldn't spend it anyway?
 652019-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)
 662019-11-07T02:17:38  <gmaxwell> Tibo: that taproot construction itself isn't recursive, there can be exactly one top level tweak.
 672019-11-07T02:18:00  <Tibo> Yes I see thanks
 682019-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.
 692019-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).
 702019-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
 712019-11-07T02:21:12  <Tibo> gmaxwell thanks
 722019-11-07T02:21:16  <Tibo> @aj
 732019-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.
 742019-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)
 752019-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.
 762019-11-07T02:22:54  <arik_> but I also agree it shouldn't really be anyone else's business
 772019-11-07T02:24:06  <sipa> arik_: you can't prove it's not tweaked
 782019-11-07T02:24:19  <sipa> unless it's generated in some other way that is in conflict with tweaking
 792019-11-07T02:24:28  <sipa> and the best way to do that... is to tweak it :)
 802019-11-07T02:24:44  <arik_> I could tweak it by an OP_RETURN and reveal that
 812019-11-07T02:24:45  *** ZmnSCPxj has joined ##taproot-bip-review
 822019-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.
 832019-11-07T02:25:31  <arik_> yes, that's better
 842019-11-07T02:25:40  <arik_> because I was gonna say that I can always tweak it twice, and choose which tweak to reveal
 852019-11-07T02:25:55  *** michaelfolkson has quit IRC
 862019-11-07T02:25:57  <gmaxwell> arik_: thats why the 'tweaking' process includes the pubkey in the hash.
 872019-11-07T02:26:18  <arik_> oops
 882019-11-07T02:26:20  <gmaxwell> So you can't do something like pick two scripts, add them, and then choose which to reveal.
 892019-11-07T02:26:42  <gmaxwell> FWIW, the earliest descriptions of 'pay to contract' had that vulnerablity.
 902019-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 :)
 912019-11-07T02:29:19  *** lightlike has quit IRC
 922019-11-07T02:29:26  <sipa> kind of, but let's not go into that
 932019-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.
 942019-11-07T02:31:37  <gmaxwell> As I was ignorantly thinking the maximum stack element limit didn't apply anymore last night.
 952019-11-07T02:31:49  *** nick_fre_ has joined ##taproot-bip-review
 962019-11-07T02:31:53  <sipa> gmaxwell: that one is even explicitly spelled out in the bip, i just forgot about it :)
 972019-11-07T02:32:02  <gmaxwell> (and a lot of limits don't apply anymore)
 982019-11-07T02:32:18  <gmaxwell> The reason for that one is stuff like quadratic OP_ROLL cost?
 992019-11-07T02:33:38  *** isho has joined ##taproot-bip-review
1002019-11-07T02:33:44  <sipa> yeah
1012019-11-07T02:34:09  <gmaxwell> Makes sense.
1022019-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
1032019-11-07T02:34:53  *** nick_freeman has quit IRC
1042019-11-07T02:36:47  <sipa> (an OP_SUCCESS could lift that limit, btw)
1052019-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?
1062019-11-07T02:38:57  <andytoshi> i believe my paper is correct but there is disagreement on whether the security model makes sense
1072019-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
1082019-11-07T02:40:03  <andytoshi> but real_or_random had some argument that this didn't cover something
1092019-11-07T02:40:16  <andytoshi> that i didn't fully grok
1102019-11-07T02:41:26  <sipa> the attacker gets to know the script, right?
1112019-11-07T02:41:53  <andytoshi> oh, right, in my proof this is the case
1122019-11-07T02:41:59  <andytoshi> i don't address privacy at all, in any form
1132019-11-07T02:42:12  <andytoshi> which is one problem with it
1142019-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?
1152019-11-07T02:42:59  <andytoshi> oh right! i implicitly assume this is not the case
1162019-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
1172019-11-07T02:43:03  <andytoshi> yep
1182019-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
1192019-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
1202019-11-07T02:45:16  <andytoshi> i don't really like this, it fails to capture any nontrivial use of script
1212019-11-07T02:45:35  <sipa> i agree - it's not complete
1222019-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
1232019-11-07T02:46:02  <sipa> but it does capture things like: what if the internal key gets reused inside one of the scripts?
1242019-11-07T02:46:05  <gmaxwell> this seems way too application specific.
1252019-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
1262019-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
1272019-11-07T02:47:00  <aj> 14m left; do feel free to interrupt with questions if you still have them
1282019-11-07T02:47:01  <andytoshi> that would be worthwhile to capture formally
1292019-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.
1302019-11-07T02:47:59  <sipa> gmaxwell: andytoshi has that
1312019-11-07T02:48:02  <andytoshi> for that, my proof is sufficient
1322019-11-07T02:48:12  <andytoshi> though it's pretty noisy because it tries to do more
1332019-11-07T02:48:18  <sipa> but i think that's a fairly low-level property
1342019-11-07T02:48:31  <arik_> Andrew, would you mind sharing a link to your paper in the chat?
1352019-11-07T02:48:45  <arik_> thanks!
1362019-11-07T02:48:59  <aj> arik_: https://github.com/apoelstra/taproot
1372019-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".
1382019-11-07T02:49:08  <arik_> thanks, aj!
1392019-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
1402019-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
1412019-11-07T02:51:00  <sipa> (i don't think anyone doubts that's the case, but a proof would still be nice)
1422019-11-07T02:51:15  *** Tibo has quit IRC
1432019-11-07T02:51:46  <gmaxwell> that should be trivial to proof, almost a definition, of H() is a random oracle.
1442019-11-07T02:51:53  <gmaxwell> s/of/if/
1452019-11-07T02:51:57  <sipa> yes.
1462019-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.
1472019-11-07T02:56:08  <arik_> yeah, I imagine as long as the field and group orders are mentioned it's trivial
1482019-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?
1492019-11-07T02:57:26  <sipa> nope.
1502019-11-07T02:57:33  <sipa> nor script.
1512019-11-07T02:57:37  *** HighOnBtc has quit IRC
1522019-11-07T02:58:08  <andytoshi> i think with segwit the only property that needed proving was that everything was committed to
1532019-11-07T02:58:32  <gmaxwell> andytoshi: no, that there weren't 'hash emulation' would have been useful to prove.
1542019-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.
1552019-11-07T02:59:20  <andytoshi> ah. yes.
1562019-11-07T02:59:23  <gmaxwell> hm I guess thats what you meant.
1572019-11-07T02:59:28  <andytoshi> technically yes
1582019-11-07T02:59:31  <andytoshi> but morally no
1592019-11-07T02:59:35  <andytoshi> i meant something dumber :P
1602019-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"
1612019-11-07T03:00:50  <aj> okay, that's the hour!
1622019-11-07T03:00:54  <aj> #endmeeting
1632019-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)
1642019-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
1652019-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
1662019-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
1672019-11-07T03:07:54  *** yas has quit IRC
1682019-11-07T03:09:39  *** andytoshi has quit IRC
1692019-11-07T03:11:00  *** andytoshi has joined ##taproot-bip-review
1702019-11-07T03:11:00  *** andytoshi has joined ##taproot-bip-review
1712019-11-07T03:39:07  *** gmaxwell has left ##taproot-bip-review
1722019-11-07T04:31:17  *** yaslama has quit IRC
1732019-11-07T04:50:35  *** isho has quit IRC
1742019-11-07T05:03:22  *** soju__ has joined ##taproot-bip-review
1752019-11-07T05:05:27  *** yaslama has joined ##taproot-bip-review
1762019-11-07T05:07:48  *** soju__ has quit IRC
1772019-11-07T05:14:33  *** eltneg has joined ##taproot-bip-review
1782019-11-07T05:29:31  *** isho has joined ##taproot-bip-review
1792019-11-07T06:01:58  *** kabaum has quit IRC
1802019-11-07T06:59:26  *** kabaum has joined ##taproot-bip-review
1812019-11-07T07:04:21  *** soju__ has joined ##taproot-bip-review
1822019-11-07T07:28:32  *** evoskuil has quit IRC
1832019-11-07T07:33:44  *** eltneg has quit IRC
1842019-11-07T07:56:38  *** soju__ has quit IRC
1852019-11-07T08:00:59  *** jonatack has quit IRC
1862019-11-07T08:20:58  *** soju__ has joined ##taproot-bip-review
1872019-11-07T08:48:22  *** john_ has quit IRC
1882019-11-07T08:51:54  *** jonatack has joined ##taproot-bip-review
1892019-11-07T08:52:25  *** soju__ has quit IRC
1902019-11-07T08:54:25  *** b10c has joined ##taproot-bip-review
1912019-11-07T08:59:14  *** kabaum has quit IRC
1922019-11-07T09:01:53  *** soju__ has joined ##taproot-bip-review
1932019-11-07T09:02:14  *** soju__ has quit IRC
1942019-11-07T09:53:29  *** kabaum has joined ##taproot-bip-review
1952019-11-07T10:45:50  *** ZmnSCPxj_ has joined ##taproot-bip-review
1962019-11-07T10:46:02  *** ZmnSCPxj has quit IRC
1972019-11-07T10:54:01  *** orfeas has joined ##taproot-bip-review
1982019-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?
1992019-11-07T11:00:22  <evoskuil[m]> ##bitcoin-taproot-sg7
2002019-11-07T11:07:17  <orfeas> thanks!
2012019-11-07T11:22:20  *** ZmnSCPxj_ has quit IRC
2022019-11-07T11:23:04  *** ZmnSCPxj_ has joined ##taproot-bip-review
2032019-11-07T11:30:27  *** ZmnSCPxj_ has quit IRC
2042019-11-07T11:31:16  *** ZmnSCPxj_ has joined ##taproot-bip-review
2052019-11-07T11:34:22  *** andytoshi has quit IRC
2062019-11-07T11:57:00  *** kabaum has quit IRC
2072019-11-07T12:10:36  *** kabaum has joined ##taproot-bip-review
2082019-11-07T12:11:39  *** ZmnSCPxj_ has quit IRC
2092019-11-07T12:12:03  *** ZmnSCPxj_ has joined ##taproot-bip-review
2102019-11-07T12:14:29  *** ZmnSCPxj_ has quit IRC
2112019-11-07T12:16:37  *** Chris_Stewart_5 has joined ##taproot-bip-review
2122019-11-07T12:30:37  *** Chris_Stewart_5 has quit IRC
2132019-11-07T12:35:11  *** justinmoon has joined ##taproot-bip-review
2142019-11-07T12:36:28  <justinmoon> Question: why is musig signing always interactive?
2152019-11-07T12:40:00  *** ZmnSCPxj_ has joined ##taproot-bip-review
2162019-11-07T12:52:10  <aj> justinmoon: because you need to share a unique set of R values per Pubkey,Message pair
2172019-11-07T12:53:14  *** r251d has quit IRC
2182019-11-07T12:53:33  *** jonatack has quit IRC
2192019-11-07T12:53:36  *** r251d has joined ##taproot-bip-review
2202019-11-07T12:55:27  *** jonatack has joined ##taproot-bip-review
2212019-11-07T13:02:20  *** stacie has joined ##taproot-bip-review
2222019-11-07T13:04:15  *** Chris_Stewart_5 has joined ##taproot-bip-review
2232019-11-07T13:12:16  <justinmoon> Pubkey is aggregate pubkey of all signers?
2242019-11-07T13:13:38  *** jonatack has quit IRC
2252019-11-07T13:14:04  *** jonatack has joined ##taproot-bip-review
2262019-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
2272019-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?
2282019-11-07T13:31:43  <aj> justinmoon: the R values need to be generated as securely as the private keys are stored
2292019-11-07T13:31:51  <aj> justinmoon: (since reusing them reveals the private key)
2302019-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
2312019-11-07T13:34:44  <justinmoon> aj: You'd need to tell your cosigners about these pre-generated R values as well?
2322019-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
2332019-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
2342019-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
2352019-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.
2362019-11-07T13:50:19  <justinmoon> aj: And deterministic-k schemes don't work because signature aggregation implies you could solve for private keys?
2372019-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
2382019-11-07T13:56:35  <aj> signed for
2392019-11-07T13:57:18  *** michaelfolkson has joined ##taproot-bip-review
2402019-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
2412019-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)
2422019-11-07T14:07:51  *** jonatack has quit IRC
2432019-11-07T14:10:14  <instagibbs> how often are QAs?
2442019-11-07T14:13:31  <aj> two a week
2452019-11-07T14:14:42  <aj> instagibbs: fyi, planning on including a link to your liquid-tapscript-case-study ipynb in the week-2 notes
2462019-11-07T14:14:51  <instagibbs> kk
2472019-11-07T14:27:44  *** Chris_Stewart_5 has quit IRC
2482019-11-07T14:29:50  *** Chris_Stewart_5 has joined ##taproot-bip-review
2492019-11-07T15:01:13  *** michaelfolkson has quit IRC
2502019-11-07T15:03:26  *** michaelfolkson has joined ##taproot-bip-review
2512019-11-07T15:23:55  *** michaelfolkson has quit IRC
2522019-11-07T15:29:57  *** kabaum has quit IRC
2532019-11-07T15:47:00  <murch> Please consider cross-posting any interesting questions to Bitcoin Stackexchange. :)
2542019-11-07T15:47:30  <murch> e.g. justinmoon's question above why MuSig signing is always interactive would be a good candidate.
2552019-11-07T15:47:56  <justinmoon> murch: i'll post that
2562019-11-07T15:48:04  <murch> Thank ye.
2572019-11-07T16:11:41  *** stacie has quit IRC
2582019-11-07T16:21:35  *** stacie has joined ##taproot-bip-review
2592019-11-07T16:21:56  *** soju__ has joined ##taproot-bip-review
2602019-11-07T16:26:53  *** jonatack has joined ##taproot-bip-review
2612019-11-07T16:29:10  *** kabaum has joined ##taproot-bip-review
2622019-11-07T16:40:59  <justinmoon> murch: https://bitcoin.stackexchange.com/questions/91534/musig-interactivity
2632019-11-07T16:42:20  <sipa> justinmoon: fwiw, we're working on a paper on deterministic nonces in musig
2642019-11-07T16:51:35  *** HighOnBtc has joined ##taproot-bip-review
2652019-11-07T17:05:01  <instagibbs> justinmoon, would also be nice to know exactly "what can go wrong" in a cold setup with musig
2662019-11-07T17:05:51  <justinmoon> instagibbs: Yes. Musig footguns.
2672019-11-07T17:06:07  *** HighOnBtc has quit IRC
2682019-11-07T17:11:30  *** kabaum has quit IRC
2692019-11-07T17:20:44  *** michaelfolkson has joined ##taproot-bip-review
2702019-11-07T17:42:14  *** andytoshi has joined ##taproot-bip-review
2712019-11-07T17:55:14  *** michaelfolkson has quit IRC
2722019-11-07T17:59:54  *** Chris_Stewart_5 has quit IRC
2732019-11-07T18:00:02  *** orfeas has quit IRC
2742019-11-07T18:05:02  *** michaelfolkson has joined ##taproot-bip-review
2752019-11-07T18:12:32  *** michaelfolkson has quit IRC
2762019-11-07T18:15:09  <murch> justinmoon: Thanks. :)
2772019-11-07T18:31:24  *** Chris_Stewart_5 has joined ##taproot-bip-review
2782019-11-07T18:36:57  *** jenseven has quit IRC
2792019-11-07T18:44:54  *** soju__ has quit IRC
2802019-11-07T18:45:03  *** Chris_Stewart_5 has quit IRC
2812019-11-07T18:51:15  *** Chris_Stewart_5 has joined ##taproot-bip-review
2822019-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
2832019-11-07T19:03:22  <justinmoon> nickler: Thanks!
2842019-11-07T19:12:07  *** stacie has quit IRC
2852019-11-07T19:19:37  *** stacie has joined ##taproot-bip-review
2862019-11-07T19:38:52  <instagibbs> nickler, "non-musig key agg" would follow the same signing rounds, right?
2872019-11-07T19:47:12  *** stacie has quit IRC
2882019-11-07T19:47:50  *** stacie has joined ##taproot-bip-review
2892019-11-07T20:03:59  *** soju__ has joined ##taproot-bip-review
2902019-11-07T20:08:13  *** soju__ has quit IRC
2912019-11-07T20:12:03  <nickler> instagibbs: if you mean DL-based and without the zkp mentioned above then yes afaik
2922019-11-07T20:12:31  <instagibbs> yes, meaning your slides thanks
2932019-11-07T20:12:31  <nickler> I posted an answer on stackexchange
2942019-11-07T20:12:45  <nickler> instagibbs: ah, yeah
2952019-11-07T20:14:41  <instagibbs> 2 roundtrips to vault is still so painful :'(
2962019-11-07T20:17:32  <sipa> nickler: very nice answer
2972019-11-07T20:17:34  <nickler> you can make it only 1 roundtrip to one of your vaults
2982019-11-07T20:18:45  <instagibbs> i mean 2 visits to vault, unless you mean only 1 visit
2992019-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
3002019-11-07T20:20:35  <nickler> so you only go to VaultC once
3012019-11-07T20:21:47  <instagibbs> Ok amortized, because N parallel sessions
3022019-11-07T20:23:34  <nickler> yeah, only works once, but also makes sense for example when you use musig in lightning
3032019-11-07T20:24:03  <instagibbs> I mean LN is super hot, not a big deal
3042019-11-07T20:24:17  <instagibbs> Latency issues aside
3052019-11-07T20:25:46  <devrandom> you can't reuse nonces for different messages, right?
3062019-11-07T20:26:18  *** kabaum has joined ##taproot-bip-review
3072019-11-07T20:26:20  <sipa> devrandom: no
3082019-11-07T20:26:52  <sipa> any known (sufficiently simple) relation between nonces used in distinct (partial) signatures leaks the private key
3092019-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
3102019-11-07T20:27:45  <sipa> you can pregenerate a million nonces
3112019-11-07T20:28:04  <sipa> as long as you make sure not to ever use the same one twice
3122019-11-07T20:28:21  <sipa> (i don't recommend that, to be clear, but in certain cases that is safe)
3132019-11-07T20:28:46  <devrandom> ah, right, you can do a batch of them
3142019-11-07T20:30:44  <devrandom> can the nonces be deterministically generated from the private keys and a counter, to reduce storage requirements?
3152019-11-07T20:31:22  <sipa> yes, but
3162019-11-07T20:31:32  <sipa> you must still guarantee they're never reused
3172019-11-07T20:31:47  <sipa> in particular, you cannot deterministically generate them from the private key and the message like in single sigs
3182019-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
3192019-11-07T20:32:15  <sipa> because then you'd like your private key by participating in two signing attempts for the same message
3202019-11-07T20:32:24  <sipa> s/like/leak/
3212019-11-07T20:34:21  *** andytoshi has quit IRC
3222019-11-07T20:55:27  *** mattleon has joined ##taproot-bip-review
3232019-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?
3242019-11-07T20:59:24  <mattleon> also here for group 3
3252019-11-07T20:59:39  <mattleon> though there was an email that mentioned another channel, I'll dig it up
3262019-11-07T21:00:09  <sipa> i think the idea is just that you'd use this channel to coordinate
3272019-11-07T21:00:24  <pyskell> devrandom, mattleon that's correct
3282019-11-07T21:00:34  <devrandom> I see it now - #bitcoin-taproot-sg3
3292019-11-07T21:00:50  <pyskell> Can we use the logging bot in other channels then sipa?
3302019-11-07T21:01:40  <pyskell> Maybe aj or moneyball know?
3312019-11-07T21:04:03  <luke-jr> meeting bot seems more useful
3322019-11-07T21:04:59  <pyskell> #help
3332019-11-07T21:40:02  *** Chris_Stewart_5 has quit IRC
3342019-11-07T21:41:46  *** ZmnSCPxj_ has quit IRC
3352019-11-07T21:53:47  *** andytoshi has joined ##taproot-bip-review
3362019-11-07T21:53:47  *** andytoshi has joined ##taproot-bip-review
3372019-11-07T22:09:23  *** mattleon has quit IRC
3382019-11-07T22:16:41  *** soju__ has joined ##taproot-bip-review
3392019-11-07T22:23:25  *** soju__ has quit IRC
3402019-11-07T22:35:43  *** soju__ has joined ##taproot-bip-review
3412019-11-07T22:35:57  *** ZmnSCPxj_ has joined ##taproot-bip-review
3422019-11-07T22:36:03  *** b10c has quit IRC
3432019-11-07T22:40:16  *** soju__ has quit IRC
3442019-11-07T22:46:28  *** stacie has joined ##taproot-bip-review
3452019-11-07T22:49:17  *** stacie has quit IRC
3462019-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
3472019-11-07T22:52:46  *** pinheadmz has quit IRC
3482019-11-07T22:54:44  *** ZmnSCPxj_ has quit IRC
3492019-11-07T23:00:17  *** pglazman has quit IRC
3502019-11-07T23:02:05  *** soju__ has joined ##taproot-bip-review
3512019-11-07T23:04:05  *** pglazman has joined ##taproot-bip-review
3522019-11-07T23:35:51  *** pglazman has quit IRC
3532019-11-07T23:42:55  *** pglazman has joined ##taproot-bip-review