12019-11-21T00:04:48  *** pglazman has quit IRC
  22019-11-21T00:43:24  *** Chris_Stewart_5 has joined ##taproot-bip-review
  32019-11-21T01:04:21  *** pglazman has joined ##taproot-bip-review
  42019-11-21T01:18:50  *** Chris_Stewart_5 has quit IRC
  52019-11-21T01:26:41  *** pglazman has quit IRC
  62019-11-21T01:52:15  <aj> waxwing: grabbing an email address this time so if there's any substantive questions they can be followed up on; you should be able to use a throwaway address of some sort if you'd like; i don't think they're strongly validated
  72019-11-21T01:53:37  *** michaelfolkson has joined ##taproot-bip-review
  82019-11-21T01:54:22  *** Chris_Stewart_5 has joined ##taproot-bip-review
  92019-11-21T02:04:02  *** soju has joined ##taproot-bip-review
 102019-11-21T02:05:58  <michaelfolkson> Hey. Is there a Q&A happening now?
 112019-11-21T02:06:44  <soju> Yes.
 122019-11-21T02:06:57  <michaelfolkson> OK thanks
 132019-11-21T02:07:34  <moneyball> Week 3 email noted that there is not one
 142019-11-21T02:07:47  <moneyball> Demand for this time has been very low
 152019-11-21T02:08:01  <sipa> moneyball: you're too late; michaelfolkson asked a question and received an answer; that qualifies as a Q&A
 162019-11-21T02:08:03  <soju> Oh oops! Sorry Michael.
 172019-11-21T02:08:11  <moneyball> Haha
 182019-11-21T02:08:28  <sipa> in fact, you're participating by improving the discussion around the provided answer
 192019-11-21T02:08:35  <moneyball> Also sipa is in here 24/7 so...
 202019-11-21T02:09:02  <michaelfolkson> Haha well that was the only question I had
 212019-11-21T02:09:48  <michaelfolkson> Ok I will join next Tuesday then I guess.... Or can we do a Q&A with sipa now?
 222019-11-21T02:09:52  <gmaxwell> Is now the time to announce that taproot is being replaced by IOTA Trinary hash?
 232019-11-21T02:10:09  <gmaxwell> just to bother all the people who weren't here?
 242019-11-21T02:10:37  *** Chris_Stewart_5 has quit IRC
 252019-11-21T02:10:42  <sipa> michaelfolkson: you're always welcome to ask questions
 262019-11-21T02:10:59  <gmaxwell> You might recieve puns instead of answers...
 272019-11-21T02:11:35  <aj> michaelfolkson: you've hacked the system man
 282019-11-21T02:11:47  <michaelfolkson> Puns will do just fine. I'm sure my study group would prefer puns anyway
 292019-11-21T02:12:42  <sipa> we can punt on actually answering
 302019-11-21T02:12:55  <michaelfolkson> Ok 1) Swapping in different elliptic curves
 312019-11-21T02:13:15  <michaelfolkson> "It would be interesting to understand what parts of the construction used in BIP Schnorr would fall apart when using a different underlying curve (such as Curve25519 which most people use). I completely understand the argument of re-using secp256k1 but it would be interesting if our choice of signature standard was still secure with other curves. The part that needs clarifying on that front is probably
 322019-11-21T02:13:15  <michaelfolkson>  footnotes 7 to 10 that may be specific to secp256k1"
 332019-11-21T02:13:57  <sipa> the only thing that would need to change is the nonce generation algorithm
 342019-11-21T02:14:00  <sipa> i believe
 352019-11-21T02:14:21  <sipa> as we can take advantage of the curve order being negligably close to 2^256
 362019-11-21T02:14:52  <michaelfolkson> Which sounds doable...?
 372019-11-21T02:15:07  <sipa> yes, but it would come at a performance and complexity cost for secp256k1
 382019-11-21T02:15:47  <sipa> for ed25519 you also have to deal with cofactor mess... secp256k1 is easy as it has cofactor 1; i haven't thought hard about how to make the whole construction deal correctly with non-1 cofactors, and i don't think it's worth spending time on
 392019-11-21T02:16:56  <michaelfolkson> This was asked under the broader discussion umbrella of whether existing (non-Bitcoin) industry implementations of Schnorr could have been leveraged in our Schnorr implementation
 402019-11-21T02:17:29  <sipa> michaelfolkson: if you want to use ed25519 somewhere, you should just use ed25519 - not bip-schnorr-adapted-to-the-ed25519-curve
 412019-11-21T02:17:47  <michaelfolkson> Or our Schnorr implementation could be used as a standard for industry and academia (non-Bitcoin, non-crypto) going forward
 422019-11-21T02:17:57  <sipa> sure
 432019-11-21T02:18:40  <sipa> that's one of the reasons why bip-schnorr is a separate bip... though i suspect most interest will come from bitcoin related projects (even if not on-chain), due to compatibility with existing key infrastructure
 442019-11-21T02:19:47  <michaelfolkson> It was briefly discussed in that LTB podcast you did that Apple are already using a Schnorr based scheme but you don't know much about it. That's because Apple don't open source it?
 452019-11-21T02:20:15  <sipa> i have no recollection of having made such a statement!
 462019-11-21T02:20:47  <michaelfolkson> Andreas: Which is the Apple one?
 472019-11-21T02:20:48  <michaelfolkson> Pieter: I have no idea but that wouldn't surprise me. That is essentially also a specialization of a Schnorr based scheme into a practical standard. We can't use ed25519 for several reasons. One of them is we like to maintain compatibility with the existing public key system we have so that things like BIP32 and everything built on it don't get invalidated. That wouldn't be a terrible thing to do but it is
 482019-11-21T02:20:49  <michaelfolkson>  simple enough to maintain compatibility so we define a Schnorr signature over the secp256k1 curve which is the same curve that Bitcoin's ECDSA scheme is currently defined over.
 492019-11-21T02:20:59  <michaelfolkson> Sure, sorry I'm not being accurate
 502019-11-21T02:21:17  <sipa> the most commonly used ec schnorr based signature scheme today is ed25519
 512019-11-21T02:21:25  <sipa> i don't actually know of any others
 522019-11-21T02:22:56  <gmaxwell> I don't think ed25519 would be particularly interesting in any case, even if we didn't care about compatiblity. The cofactor really is a big nussance. Existing implementations don't have non-malleable and consistent behavior, and or require stuff like the MSB of the private key be set (not compatible with BIP32 like derrivation), so you'd need to use a specialized implementation anyways.
 532019-11-21T02:22:59  <sipa> not sure what the "apple" does in that transcript, maybe the transcript is wrong, but i don't know anything relating apple and ed25519 or schnorr
 542019-11-21T02:23:51  <aj> Pieter: There's a number of other signature schemes that are essentially Schnorr based but don't go by that name. One of them is ed25519.
 552019-11-21T02:23:52  <aj> Andreas: Which is the Apple one?
 562019-11-21T02:23:57  <aj> was the prior context
 572019-11-21T02:24:03  <michaelfolkson> http://diyhpl.us/wiki/transcripts/lets-talk-bitcoin-podcast/2019-06-09-ltb-pieter-wuille-jonas-nick/
 582019-11-21T02:24:10  <michaelfolkson> Yeah thanks aj
 592019-11-21T02:24:31  <michaelfolkson> If the transcript is wrong then that'd be my fault too lol
 602019-11-21T02:25:33  <sipa> also, secp256k1 has 1.41 bits more security :p
 612019-11-21T02:26:25  <michaelfolkson> Any open source non-Bitcoin/crypto industry Schnorr libraries you're aware of? Google generally open source their crypto libraries? I'm assuming no
 622019-11-21T02:26:41  <sipa> in order for there to be a library there must be scheme to implement
 632019-11-21T02:26:53  <michaelfolkson> Again the context being "The reason I'm interested in that is that if BIP Schnorr can be re-used securely and efficiently over other curves, other projects might implement it and that may bring more people to review its security (if Apple wanted to use it for example)"
 642019-11-21T02:27:16  <aj> https://developer.apple.com/documentation/cryptokit -- does ed25519 presumably with their schnorr std, and p256 and p384 with ecdsa
 652019-11-21T02:27:20  <michaelfolkson> Future industry/academia collaboration
 662019-11-21T02:28:55  <sipa> michaelfolkson: i think all the relevant minor things in bip-schnorr are essentially specific to the curve... like leveraring that negating a public key changes the quadratic residuosity of y, that there is no cofactor, that the curve order is close to 2^256
 672019-11-21T02:29:15  <sipa> if you'd want to adapt bip-schnorr to work with the ed25519 curve, i think you'd pretty much exactly end up with just ed25519
 682019-11-21T02:29:21  <gmaxwell> sipa: to be fair the negation thing works for mot fields.
 692019-11-21T02:29:34  <sipa> mot fields?
 702019-11-21T02:29:37  <gmaxwell> sipa: unfortunately that isn't true, because ed25519 is underspecified, permits malleablity, etc.
 712019-11-21T02:29:42  <gmaxwell> sipa: most*
 722019-11-21T02:30:09  <sipa> gmaxwell: half of them, i believe?
 732019-11-21T02:30:38  <gmaxwell> sipa: E.g. ed25519 verfiers disagree on if 0 is a valid public key,  and there are several variations of range checks/modular reductions for S, some of which allow malleability.
 742019-11-21T02:30:58  <gmaxwell> In the original ed25519 paper they explicitly mention malleability and dismiss it as not interesting.
 752019-11-21T02:31:21  <sipa> gmaxwell: yeah, that's fair - but my point is that the extent to which bip-schnorr deviates from the most naive schnorr implementation you can come up with is very much dependent on the curve we have
 762019-11-21T02:31:31  <gmaxwell> "Malleability.We also see no relevance of “malleability” to the standard defini-tion of signature security."
 772019-11-21T02:31:41  <gmaxwell> Yes, thats a fair point.
 782019-11-21T02:32:17  *** HighOnBtc has quit IRC
 792019-11-21T02:33:13  <michaelfolkson> In non-blockchain use cases they're right not to be worried about malleability right?
 802019-11-21T02:33:25  <sipa> they might not, it depends on the use case
 812019-11-21T02:33:49  <michaelfolkson> Some of these problems seem cryptocurrency/blockchain specific which means we need different things
 822019-11-21T02:34:02  <gmaxwell> in any kind of consensus system malleability is a fatal problem, but it is also a problem in other systems.
 832019-11-21T02:34:17  <michaelfolkson> Ok, interesting
 842019-11-21T02:34:25  <gmaxwell> For example x509 certificate blacklisting uses the hash of the certificates, so malleability can let you bypass a blacklist.
 852019-11-21T02:34:26  *** jonatack has quit IRC
 862019-11-21T02:34:58  <gmaxwell> I think the sentence from the ed25519 paper is technically correct: malleability is irrelevant to the standard definition of signature security.
 872019-11-21T02:35:02  <sipa> i think one thing where do go further than existing standards is in having well-defined batch validation (we guarantee with extremely high probability that batch verification will always give the same result as non-batch validation, even in the presence of malicious signers)
 882019-11-21T02:35:07  <gmaxwell> But the standard defintion isn't sufficient. :)
 892019-11-21T02:35:42  <gmaxwell> (and ed25519 is not worse than the sea of random ECDSA stuff that was out before it)
 902019-11-21T02:36:04  <sipa> and in order for that to be the case, we actually had to make non-batch validation sightly more complex
 912019-11-21T02:37:06  <gmaxwell> sipa: I think that ed25519 is well defined batch verifyable (ignoring the parts of its validity which aren't well defined at all)
 922019-11-21T02:37:39  <sipa> possibly, i'm not sure
 932019-11-21T02:37:58  <gmaxwell> (they send explicit R signs, and weren't aware of the projective comparison trick we would otherwise use for non-batch)
 942019-11-21T02:38:27  <gmaxwell> but yeah you're right, I wouldn't be too surprised if scalar ed25519 verifiers actually fail to check R's sign.
 952019-11-21T02:38:58  <sipa> but i guess this is perhaps something to put formally: a signer (with access to private key) who can cause different verifiers to disagree is considered an attack
 962019-11-21T02:39:22  <sipa> for someone without a private key, that's trivial, as they shouldn't be able to cause verifiers to return success in the first place
 972019-11-21T02:39:38  <sipa> and for honest signers that's also not a problem, as soundness guarantess that their signatures will always validate
 982019-11-21T02:40:46  <gmaxwell> sipa: https://github.com/sipa/bips/issues/110
 992019-11-21T02:40:59  <sipa> gmaxwell: i know
1002019-11-21T02:41:06  <sipa> i was trying to word in a more formal way
1012019-11-21T02:41:18  <gmaxwell> 'I think the objective of this specification is that every input string is consistently rejected or accepted by all conforming implementations, regardless of how the input string was constructed. This is not an objective that normally shows up for other signature systems, instead they just want the weaker property of "signatures constructed with the specified procedure will be accepted and
1022019-11-21T02:41:18  <gmaxwell> someone who doesn't know the private key can not construct an accepted string".'
1032019-11-21T02:43:49  <michaelfolkson> Let me know when ready for new question, don't want to interrupt trail of thought :)
1042019-11-21T02:45:51  <gmaxwell> shoot
1052019-11-21T02:46:36  <sipa> *bang*
1062019-11-21T02:47:11  <michaelfolkson> Ok. So again in the broader context of this BIP review process there were a couple in my study group who were unsure how they could best add value. Working on use cases of Taproot or trying to get engaged in security proof discussion, attempting to make Musig secure etc
1072019-11-21T02:47:51  <moneyball> I’m very happy with the quality of this canceled Q&A session 🙃
1082019-11-21T02:48:07  <michaelfolkson> This blog post from Jonas was great, educational but a couple of people were wondering whether to just read it for education or to go down this rabbit hole https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da
1092019-11-21T02:48:07  <aj> (should cancel more of them?)
1102019-11-21T02:48:52  <michaelfolkson> If they were to go down this rabbit hole how best would they engage, find out more about the attempts to make Musig secure for example?
1112019-11-21T02:49:24  <michaelfolkson> Lol
1122019-11-21T02:49:37  <sipa> michaelfolkson: making things secure is hard, as you never really get a positive answer
1132019-11-21T02:51:31  <sipa> it of course depends on people background, but i suspect that for many of them probably a more useful contribution is trying to work out use cases
1142019-11-21T02:51:37  <sipa> and seeing what roadblocks you run into
1152019-11-21T02:53:13  <michaelfolkson> But going through commit history of say the Blockstream secp256k1 library to understand what was there before and what was changed would be good idea if they wanted to go this route (identifying potentially more weaknesses/attack vectors)
1162019-11-21T02:53:33  <waxwing> gmaxwell, "malleability is irrelevant to the standard definition of signature security." <-- well it seems to be pretty relevant to SUF-CMA :)
1172019-11-21T02:53:51  <michaelfolkson> Obviously not for everyone. But I've a got a couple of smart cookies in my study group
1182019-11-21T02:54:48  <waxwing> michaelfolkson, the best way to go down the musig rabbit hole is probably to read the paper.
1192019-11-21T02:54:54  <waxwing> i mean not all of it necessarily :)
1202019-11-21T02:55:05  <sipa> michaelfolkson: well musig has a security proof - it's based on certain assumptions, and obviously reality does not necessarily match the model used to prove its security
1212019-11-21T02:56:01  <sipa> michaelfolkson: but i believe that shifts the question not from "is this scheme - in abstract - secure or not", but whether implementations actually match the abstract scheme
1222019-11-21T02:56:45  <sipa> i think reading about failed predecessors and insecure modifications is helpful in teaching you what kind of things to pay attention to
1232019-11-21T02:57:09  <sipa> but not in analysing the scheme itself, only in making sure you're not deviating from it in relevant ways
1242019-11-21T02:57:46  <sipa> e.g. if you hadn't read https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da, maybe you'd never have considered that precomputing nonces would be a meaningful deviation from the abstract scheme presented in the paper
1252019-11-21T02:58:12  <waxwing> for example, what jonas talks about in that excellent blog is a good example of one potential problem, but you can see a simpler example of wagner's attack described in the paper, which gives a nice insight into why musig is the way it is.
1262019-11-21T02:58:26  <waxwing> i mean for certain values of 'simpler' :)
1272019-11-21T02:59:52  <michaelfolkson> But what to recommend reading/reviewing after the blog post and after the Musig paper?
1282019-11-21T03:00:52  <waxwing> i almost feel like you want to read other stuff *before* that, not after :) the musig paper is an end point of a lot of prior research.
1292019-11-21T03:00:58  <waxwing> but maybe you mean like code or something?
1302019-11-21T03:01:03  <michaelfolkson> Yeah
1312019-11-21T03:01:17  <sipa> fwiw, the proofs in the musig paper are unreadable to me, and don't convey any understanding about what is secure and insecure to me
1322019-11-21T03:01:49  <sipa> for example, gregory neven once told me that he was talking to someone implementing his bn06 scheme, and told them that it was absolutely required that the non precommitment round was really required
1332019-11-21T03:02:08  <sipa> and then the person he was talking to said they'd just send the hash of the nonce and nonce in the same message
1342019-11-21T03:02:23  <waxwing> heh
1352019-11-21T03:02:25  <sipa> clearly they had no clue what a round in a protocol, and the necessity for it, was
1362019-11-21T03:02:42  <waxwing> as long as you serialize them in the right order, it's secure :)
1372019-11-21T03:02:45  <sipa> but that's not an unreasonable mistake to make for someone who isn't familiar with these sort of protocols
1382019-11-21T03:03:27  <sipa> so i think that learning about near-misses of this kind can teach you to better distinguish between what implementation variations are reasonable to make and which ones aren't
1392019-11-21T03:04:46  <michaelfolkson> Ok that's been an hour. I was going to ask about use cases as well but that can wait for another Q&A
1402019-11-21T03:05:24  <michaelfolkson> Thanks a lot all (especially as it wasn't supposed to happen....)
1412019-11-21T03:05:25  <waxwing> i could play devil's advocate though: as systems get more complex, it's arguably of less and less value to take that incremental approach. for example learning what an extractor is in a sigma protocol means you actually have a sense of what defends against forgery, learning about 'attack 1', 'attack 2' is less helpful. since there's always an attack 3.
1422019-11-21T03:05:46  <aj> michaelfolkson: well, "ask questions any time" is okay too, doesn't have to be in a Q&A slot
1432019-11-21T03:06:00  <michaelfolkson> Ok cool
1442019-11-21T03:06:40  <sipa> waxwing: my point isn't that learning about these failures will teach you how to build a secure protocol on itself
1452019-11-21T03:07:17  <sipa> but that because there are always deviations between theory and practice, and failures often teach you what kind of deviations are red flags
1462019-11-21T03:09:15  <gmaxwell> It's tricky of course because learning a lit of mistakes and avoiding every one doesn't make it secure.  Really the purpose of learning is to get a feel for how brittle the constructions are.
1472019-11-21T03:09:18  <aj> implementing variants of this with weaker cryptographic primitives so that these attacks are practical might be worthwhile -- "here's how you can break a weaker version with this procedure, so it's fair to expect the NSA/mafia/google can break real variants if implemented poorly in the near future"
1482019-11-21T03:09:52  <gmaxwell> aj: for a lot of this stuff, at least for fancy uses, minor errors mean anyone can break it. :(
1492019-11-21T03:10:14  <waxwing> my 'less helpful' is unhelpful :) but, i think there's a point there about growing complexity and fundamental principles.
1502019-11-21T03:10:54  <waxwing> right gmaxwell nonce fragility in these sig systems is arguably kinda unacceptable. for example.
1512019-11-21T03:11:38  <gmaxwell> for example, reading jonas' post on round reduction being insecure made me realize another protocol I'd suggested to someone a few years ago was insecure.  (One where you publish a bunch of nonces for single show signatures, and can get a signer to sign one signature for each nonce)
1522019-11-21T03:13:08  <gmaxwell> (it's insecure because you can accept the nonces, then grind a lot of messages to setup a wagner attack to solve for an additional signature -- just like the problem with naieve blind signatures found in the lit)
1532019-11-21T03:14:30  <gmaxwell> instead if you use a single show signature, you really need to construct it using a hash commitment instead of exposing the nonce itself.
1542019-11-21T03:15:15  <gmaxwell> if you search around you'll see a number of times people have suggested some OP_SUBSTR sort of single show signature ... bad idea.
1552019-11-21T03:24:38  *** Chris_Stewart_5 has joined ##taproot-bip-review
1562019-11-21T03:32:27  *** michaelfolkson has quit IRC
1572019-11-21T04:16:13  *** Chris_Stewart_5 has quit IRC
1582019-11-21T04:26:22  *** pglazman has joined ##taproot-bip-review
1592019-11-21T04:34:57  *** pglazman has quit IRC
1602019-11-21T04:34:57  *** rottensox has quit IRC
1612019-11-21T04:52:13  *** ZmnSCPxj has joined ##taproot-bip-review
1622019-11-21T04:53:09  <ZmnSCPxj> Given the many traps that implementation of multisignatures has, would a bip-musig describing the "one true way" make sense?
1632019-11-21T04:53:45  <ZmnSCPxj> Although of course a good design for libsecp256k1 MuSig support would be better, but perhaps the rationale for that design can point to the bip-musig
1642019-11-21T04:54:50  <ZmnSCPxj> And at least discourage roll-your-own
1652019-11-21T04:55:16  *** ZmnSCPxj has quit IRC
1662019-11-21T05:05:26  <gmaxwell> the bip would probably just end up being a transliteration of the code.
1672019-11-21T05:05:36  <gmaxwell> like getting it right is a billion and one tiny detals.
1682019-11-21T05:11:09  <gmaxwell> I fully expect we're going to see people mess this up. In particular since _most_ of the attacks require malicious signers and malicious signers are .. I'm not sure of the word for it. Clearly malicious signers are considered possible or we wouldn't bother with multisig, but I think most multisig users act as if the other signers will not be malicious.
1692019-11-21T05:11:49  <gmaxwell> consider how copay was letting the transaction author set the sighash flag however they wanted, including in ways that would let them trigger the sighash single weird behavior.
1702019-11-21T05:12:28  <gmaxwell> or the existance of hardware wallets without screens.
1712019-11-21T07:35:56  *** molz has quit IRC
1722019-11-21T07:37:34  *** ZmnSCPxj has joined ##taproot-bip-review
1732019-11-21T07:38:30  <ZmnSCPxj> gmaxwell: thank you. So we simply say "do not roll your own MuSig, use libsecp256k1" and hope that somebody ports it correctly to e.g. JavaScript (ha, ha)?
1742019-11-21T07:39:46  <ZmnSCPxj> which brings me to the problem of MuSig-in-MuSig, which seems not possible with the current exchange hash-commit-to-R, exchange R, exchange s
1752019-11-21T07:40:46  <ZmnSCPxj> Though I suppose the point of MuSig-in-MuSig is not that useful, other than nodelets (which suck anyway) and the general principle that a MuSig participant should not have to prove it is a singleton or aggregate
1762019-11-21T07:41:49  <gmaxwell> ZmnSCPxj: web assembly + that clang compiler? :P
1772019-11-21T07:42:16  <ZmnSCPxj> Does that work on-server in NodeJS?
1782019-11-21T07:43:03  <gmaxwell> Apparently. (though server nodejs can call C)
1792019-11-21T07:43:33  <ZmnSCPxj> yes, looks like it
1802019-11-21T07:44:05  <gmaxwell> I think someone writing a spec document would be useful, but less useful than implementing it.
1812019-11-21T07:48:14  <ZmnSCPxj> Anyway, given https://eprint.iacr.org/2018/417.pdf , can someone explaine to a non-mathist what it shows about 2-round MuSig?
1822019-11-21T08:09:45  *** jonatack has joined ##taproot-bip-review
1832019-11-21T08:16:59  *** ZmnSCPxj has quit IRC
1842019-11-21T08:33:06  *** jonatack_ has joined ##taproot-bip-review
1852019-11-21T08:36:29  *** jonatack has quit IRC
1862019-11-21T09:13:57  *** andytoshi has quit IRC
1872019-11-21T10:52:24  *** Guest61 has quit IRC
1882019-11-21T10:57:38  *** tecnovert has quit IRC
1892019-11-21T11:00:03  *** tecnovert has joined ##taproot-bip-review
1902019-11-21T11:08:17  *** jonatack_ has quit IRC
1912019-11-21T11:32:49  *** orfeas has joined ##taproot-bip-review
1922019-11-21T11:49:18  <waxwing> ZmnSCPxj_, I believe that the 2 round version of musig is reducible to the k-sum problem (i.e. what wagner attack attacks), given concurrent/parallel signing. so it's rather similar to what nickler writes about in his recent blog but not exactly the same. whether it's practically possible to do this (how many concurrent signing operations is realistic?) i have no idea.
1932019-11-21T11:49:33  <waxwing> but i could be wrong.
1942019-11-21T11:50:41  <waxwing> also, there's kind of an intuition given there: because if the R-values are not fixed upfront then in a multi-user protocol it gives wiggle room for an attacker to choose their component of R maliciously to bias something.
1952019-11-21T11:51:55  <ZmnSCPxj_> Yes, but if e.g. a HW wallet implements MuSig signing code, it may be possible for malware on PC to somehow simulate many "concurrent" signing operations by triggering aborts
1962019-11-21T11:52:40  <nickler> I made a diagram of the attack on 2-round MuSig (not sure how helpful it is) https://mobile.twitter.com/n1ckler/status/1100429537328930816 but it's very similar to the attack in the medium article
1972019-11-21T11:52:46  *** Chris_Stewart_5 has joined ##taproot-bip-review
1982019-11-21T11:52:53  <waxwing> i do note that in the discussion of CoSi (the sig scheme they spend more time on, and then basically say it cross-applies to musig), they say that if operation can be restricted to concurrent and also assuming KOSK then it *can* be proven secure.
1992019-11-21T11:53:45  <ZmnSCPxj_> KOSK == ?
2002019-11-21T11:54:10  *** dr-orlovsky has joined ##taproot-bip-review
2012019-11-21T11:54:20  <waxwing> 'knowledge of secret key' ; but it's new to me also :)
2022019-11-21T11:54:40  <waxwing> sorry 'restricted to concurrent' i meant restricted to  serial, duh
2032019-11-21T11:56:22  <waxwing> oh nice diagram nickler thanks
2042019-11-21T11:58:02  <waxwing> here's my 10000 ft view on all this: in the fiat shamir transform you take an interactive protocol for proving something, and you make it non-interactive by hashing everything up to the step where the Verifier issues a challenge.
2052019-11-21T11:58:21  <waxwing> and you replace that Verifier's challenge with a hash of what's gone before, as a way to kind of "freeze/bind" everything that's happened before.
2062019-11-21T11:58:44  <waxwing> the problem is, if you only hash an *aggregate* of what's happened before (Sigma of R_i for example) you've given wiggle room
2072019-11-21T11:58:51  <waxwing> because there are many ways to sum to that sum
2082019-11-21T11:59:01  <waxwing> instead you have to freeze/bind each *individual* element.
2092019-11-21T11:59:50  <waxwing> (this is really not a correct summary of the whole situation, but i feel like it gives some clue)
2102019-11-21T12:12:49  <nickler> waxwing: though problem in 2-round musig and late-message musig is not that there are many ways to sum to that sum but that attacker can just compute output of hash before having to commit to a contribution (which isn't helpful in single-signer case)
2112019-11-21T13:11:52  <ZmnSCPxj_> thank you nickler and waxwing, this helps clarify the issue and it seems my understanding is mostly on track
2122019-11-21T13:36:56  *** HighOnBtc has joined ##taproot-bip-review
2132019-11-21T13:45:27  *** Chris_Stewart_5 has quit IRC
2142019-11-21T14:00:23  *** Chris_Stewart_5 has joined ##taproot-bip-review
2152019-11-21T14:12:45  *** andytoshi has joined ##taproot-bip-review
2162019-11-21T14:12:45  *** andytoshi has joined ##taproot-bip-review
2172019-11-21T14:24:12  *** shesek has quit IRC
2182019-11-21T14:24:36  *** shesek has joined ##taproot-bip-review
2192019-11-21T14:33:06  *** ZmnSCPxj_ has quit IRC
2202019-11-21T14:34:02  *** ZmnSCPxj_ has joined ##taproot-bip-review
2212019-11-21T14:35:00  *** davterra has quit IRC
2222019-11-21T14:41:38  *** davterra has joined ##taproot-bip-review
2232019-11-21T15:15:20  *** andytoshi has quit IRC
2242019-11-21T15:25:24  *** midnight is now known as midnightmagic
2252019-11-21T15:26:16  *** midnightmagic is now known as midnight
2262019-11-21T16:56:47  <devrandom> "Synthetic nonces When a random number generator (RNG) is available, 32 bytes of RNG output can be appended to the input to hashBIPSchnorrDerive" - just making sure - is this safe even if it causes the signer to sign the same message with two different nonces?  or does the signer have to be stateful if this is used?
2272019-11-21T16:58:47  <nickler> signing the same message with different nonces is fine, the issue would be different messages with the same nonce
2282019-11-21T16:59:40  <nickler> if this is used the signer doesn't have to be stateful. The RNG output is just belt-and-suspenders. Though I'm unsure about the specific attacks that synthetic nonces would harden against
2292019-11-21T17:00:37  <devrandom> got it, thank you
2302019-11-21T17:43:43  *** orfeas has quit IRC
2312019-11-21T18:04:07  <dr-orlovsky> sipa: as a part of our work on RGB project (assets over Bitcoin/LN) we have developed a generic standard for collision-resistant public key tweaking, which can be used for putting arbitrary commitment within a given public key - a generalisation of original pay-to-contract scheme with inclusion of tagged hashes and HMAC instead of simple hash. Of course we are looking to have it be compatible with taproot. Am I right that with
2322019-11-21T18:04:07  <dr-orlovsky>  Taproot we can still commit to the internal public key without any issues? The standard is defined here: https://github.com/LNP-BP/lnpbps/blob/master/lnpbp-0001.md
2332019-11-21T18:08:01  *** jonatack_ has joined ##taproot-bip-review
2342019-11-21T18:08:03  <sipa> dr-orlovsky: the bip-taproot tweaking commits to the internal public key
2352019-11-21T18:09:13  <dr-orlovsky> so the internal pubkey can be tweaked itself, i.e. for instance represent Alice+Bob pubkeys + some tweak factor external to taproot?
2362019-11-21T18:09:37  <sipa> sure
2372019-11-21T18:10:00  <dr-orlovsky> thanks
2382019-11-21T18:15:27  *** rottensox has joined ##taproot-bip-review
2392019-11-21T18:15:56  *** andrewtoth has joined ##taproot-bip-review
2402019-11-21T18:29:38  *** jonatack_ has quit IRC
2412019-11-21T18:29:52  *** jonatack has joined ##taproot-bip-review
2422019-11-21T19:32:25  *** jonatack has quit IRC
2432019-11-21T19:52:12  *** mol has joined ##taproot-bip-review
2442019-11-21T19:57:40  *** Chris_Stewart_5 has quit IRC
2452019-11-21T20:23:04  <devrandom> has anybody looked into the applicability of a MuSig-like scheme to the Lightning protocol?
2462019-11-21T20:26:26  *** andrewtoth has quit IRC
2472019-11-21T20:26:26  *** mryandao has quit IRC
2482019-11-21T20:26:26  *** afk11 has quit IRC
2492019-11-21T20:26:26  *** sipa has quit IRC
2502019-11-21T20:28:24  <instagibbs_> yes
2512019-11-21T20:28:30  <instagibbs_> nickler might have something written down or resources
2522019-11-21T20:34:15  *** mryandao has joined ##taproot-bip-review
2532019-11-21T20:36:55  *** afk11 has joined ##taproot-bip-review
2542019-11-21T20:42:01  *** jonatack has joined ##taproot-bip-review
2552019-11-21T20:42:04  <devrandom> very interested in that - would put actual math behind the multi-signer aspect of https://medium.com/@devrandom/securing-lightning-nodes-39410747734b
2562019-11-21T20:43:55  *** sipa has joined ##taproot-bip-review
2572019-11-21T20:55:04  *** andrewtoth has joined ##taproot-bip-review
2582019-11-21T21:04:56  *** dr-orlovsky has quit IRC
2592019-11-21T21:05:35  *** dr-orlovsky has joined ##taproot-bip-review
2602019-11-21T21:09:06  *** justinmoon_ has joined ##taproot-bip-review
2612019-11-21T21:09:37  *** jkczyz_ has joined ##taproot-bip-review
2622019-11-21T21:10:10  *** waxwing_ has joined ##taproot-bip-review
2632019-11-21T21:10:23  *** andrewtoth_ has joined ##taproot-bip-review
2642019-11-21T21:11:48  *** andrewtoth has quit IRC
2652019-11-21T21:12:18  *** justinmoon has quit IRC
2662019-11-21T21:12:19  *** waxwing has quit IRC
2672019-11-21T21:12:19  *** jkczyz has quit IRC
2682019-11-21T21:16:56  *** andrewtoth_ has quit IRC
2692019-11-21T21:32:39  *** Chris_Stewart_5 has joined ##taproot-bip-review
2702019-11-21T21:44:14  *** waxwing_ is now known as waxwing
2712019-11-21T21:44:28  *** waxwing has joined ##taproot-bip-review
2722019-11-21T21:46:07  <nickler> devrandom: if the question is just about using musig in lightning instead of op_checkmultisig and using adaptor sigs I'd shill my own writeup https://github.com/ElementsProject/scriptless-scripts/blob/master/md/multi-hop-locks.md
2732019-11-21T21:47:29  <nickler> if you're asking about splitting up your lightning keys, you probably want the nested musig scheme that ZmnSCPxj_ mentioned
2742019-11-21T22:00:38  *** andrewtoth_ has joined ##taproot-bip-review
2752019-11-21T22:54:26  *** Chris_Stewart_5 has quit IRC
2762019-11-21T23:41:18  *** HighOnBtc has quit IRC