1 2019-11-21T00:04:48  *** pglazman has quit IRC
  2 2019-11-21T00:43:24  *** Chris_Stewart_5 has joined ##taproot-bip-review
  3 2019-11-21T01:04:21  *** pglazman has joined ##taproot-bip-review
  4 2019-11-21T01:18:50  *** Chris_Stewart_5 has quit IRC
  5 2019-11-21T01:26:41  *** pglazman has quit IRC
  6 2019-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
  7 2019-11-21T01:53:37  *** michaelfolkson has joined ##taproot-bip-review
  8 2019-11-21T01:54:22  *** Chris_Stewart_5 has joined ##taproot-bip-review
  9 2019-11-21T02:04:02  *** soju has joined ##taproot-bip-review
 10 2019-11-21T02:05:58  <michaelfolkson> Hey. Is there a Q&A happening now?
 11 2019-11-21T02:06:44  <soju> Yes.
 12 2019-11-21T02:06:57  <michaelfolkson> OK thanks
 13 2019-11-21T02:07:34  <moneyball> Week 3 email noted that there is not one
 14 2019-11-21T02:07:47  <moneyball> Demand for this time has been very low
 15 2019-11-21T02:08:01  <sipa> moneyball: you're too late; michaelfolkson asked a question and received an answer; that qualifies as a Q&A
 16 2019-11-21T02:08:03  <soju> Oh oops! Sorry Michael.
 17 2019-11-21T02:08:11  <moneyball> Haha
 18 2019-11-21T02:08:28  <sipa> in fact, you're participating by improving the discussion around the provided answer
 19 2019-11-21T02:08:35  <moneyball> Also sipa is in here 24/7 so...
 20 2019-11-21T02:09:02  <michaelfolkson> Haha well that was the only question I had
 21 2019-11-21T02:09:48  <michaelfolkson> Ok I will join next Tuesday then I guess.... Or can we do a Q&A with sipa now?
 22 2019-11-21T02:09:52  <gmaxwell> Is now the time to announce that taproot is being replaced by IOTA Trinary hash?
 23 2019-11-21T02:10:09  <gmaxwell> just to bother all the people who weren't here?
 24 2019-11-21T02:10:37  *** Chris_Stewart_5 has quit IRC
 25 2019-11-21T02:10:42  <sipa> michaelfolkson: you're always welcome to ask questions
 26 2019-11-21T02:10:59  <gmaxwell> You might recieve puns instead of answers...
 27 2019-11-21T02:11:35  <aj> michaelfolkson: you've hacked the system man
 28 2019-11-21T02:11:47  <michaelfolkson> Puns will do just fine. I'm sure my study group would prefer puns anyway
 29 2019-11-21T02:12:42  <sipa> we can punt on actually answering
 30 2019-11-21T02:12:55  <michaelfolkson> Ok 1) Swapping in different elliptic curves
 31 2019-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
 32 2019-11-21T02:13:15  <michaelfolkson>  footnotes 7 to 10 that may be specific to secp256k1"
 33 2019-11-21T02:13:57  <sipa> the only thing that would need to change is the nonce generation algorithm
 34 2019-11-21T02:14:00  <sipa> i believe
 35 2019-11-21T02:14:21  <sipa> as we can take advantage of the curve order being negligably close to 2^256
 36 2019-11-21T02:14:52  <michaelfolkson> Which sounds doable...?
 37 2019-11-21T02:15:07  <sipa> yes, but it would come at a performance and complexity cost for secp256k1
 38 2019-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
 39 2019-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
 40 2019-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
 41 2019-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
 42 2019-11-21T02:17:57  <sipa> sure
 43 2019-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
 44 2019-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?
 45 2019-11-21T02:20:15  <sipa> i have no recollection of having made such a statement!
 46 2019-11-21T02:20:47  <michaelfolkson> Andreas: Which is the Apple one?
 47 2019-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
 48 2019-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.
 49 2019-11-21T02:20:59  <michaelfolkson> Sure, sorry I'm not being accurate
 50 2019-11-21T02:21:17  <sipa> the most commonly used ec schnorr based signature scheme today is ed25519
 51 2019-11-21T02:21:25  <sipa> i don't actually know of any others
 52 2019-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.
 53 2019-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
 54 2019-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.
 55 2019-11-21T02:23:52  <aj> Andreas: Which is the Apple one?
 56 2019-11-21T02:23:57  <aj> was the prior context
 57 2019-11-21T02:24:03  <michaelfolkson> http://diyhpl.us/wiki/transcripts/lets-talk-bitcoin-podcast/2019-06-09-ltb-pieter-wuille-jonas-nick/
 58 2019-11-21T02:24:10  <michaelfolkson> Yeah thanks aj
 59 2019-11-21T02:24:31  <michaelfolkson> If the transcript is wrong then that'd be my fault too lol
 60 2019-11-21T02:25:33  <sipa> also, secp256k1 has 1.41 bits more security :p
 61 2019-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
 62 2019-11-21T02:26:41  <sipa> in order for there to be a library there must be scheme to implement
 63 2019-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)"
 64 2019-11-21T02:27:16  <aj> https://developer.apple.com/documentation/cryptokit -- does ed25519 presumably with their schnorr std, and p256 and p384 with ecdsa
 65 2019-11-21T02:27:20  <michaelfolkson> Future industry/academia collaboration
 66 2019-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
 67 2019-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
 68 2019-11-21T02:29:21  <gmaxwell> sipa: to be fair the negation thing works for mot fields.
 69 2019-11-21T02:29:34  <sipa> mot fields?
 70 2019-11-21T02:29:37  <gmaxwell> sipa: unfortunately that isn't true, because ed25519 is underspecified, permits malleablity, etc.
 71 2019-11-21T02:29:42  <gmaxwell> sipa: most*
 72 2019-11-21T02:30:09  <sipa> gmaxwell: half of them, i believe?
 73 2019-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.
 74 2019-11-21T02:30:58  <gmaxwell> In the original ed25519 paper they explicitly mention malleability and dismiss it as not interesting.
 75 2019-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
 76 2019-11-21T02:31:31  <gmaxwell> "Malleability.We also see no relevance of “malleability” to the standard defini-tion of signature security."
 77 2019-11-21T02:31:41  <gmaxwell> Yes, thats a fair point.
 78 2019-11-21T02:32:17  *** HighOnBtc has quit IRC
 79 2019-11-21T02:33:13  <michaelfolkson> In non-blockchain use cases they're right not to be worried about malleability right?
 80 2019-11-21T02:33:25  <sipa> they might not, it depends on the use case
 81 2019-11-21T02:33:49  <michaelfolkson> Some of these problems seem cryptocurrency/blockchain specific which means we need different things
 82 2019-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.
 83 2019-11-21T02:34:17  <michaelfolkson> Ok, interesting
 84 2019-11-21T02:34:25  <gmaxwell> For example x509 certificate blacklisting uses the hash of the certificates, so malleability can let you bypass a blacklist.
 85 2019-11-21T02:34:26  *** jonatack has quit IRC
 86 2019-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.
 87 2019-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)
 88 2019-11-21T02:35:07  <gmaxwell> But the standard defintion isn't sufficient. :)
 89 2019-11-21T02:35:42  <gmaxwell> (and ed25519 is not worse than the sea of random ECDSA stuff that was out before it)
 90 2019-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
 91 2019-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)
 92 2019-11-21T02:37:39  <sipa> possibly, i'm not sure
 93 2019-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)
 94 2019-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.
 95 2019-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
 96 2019-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
 97 2019-11-21T02:39:38  <sipa> and for honest signers that's also not a problem, as soundness guarantess that their signatures will always validate
 98 2019-11-21T02:40:46  <gmaxwell> sipa: https://github.com/sipa/bips/issues/110
 99 2019-11-21T02:40:59  <sipa> gmaxwell: i know
100 2019-11-21T02:41:06  <sipa> i was trying to word in a more formal way
101 2019-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
102 2019-11-21T02:41:18  <gmaxwell> someone who doesn't know the private key can not construct an accepted string".'
103 2019-11-21T02:43:49  <michaelfolkson> Let me know when ready for new question, don't want to interrupt trail of thought :)
104 2019-11-21T02:45:51  <gmaxwell> shoot
105 2019-11-21T02:46:36  <sipa> *bang*
106 2019-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
107 2019-11-21T02:47:51  <moneyball> I’m very happy with the quality of this canceled Q&A session 🙃
108 2019-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
109 2019-11-21T02:48:07  <aj> (should cancel more of them?)
110 2019-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?
111 2019-11-21T02:49:24  <michaelfolkson> Lol
112 2019-11-21T02:49:37  <sipa> michaelfolkson: making things secure is hard, as you never really get a positive answer
113 2019-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
114 2019-11-21T02:51:37  <sipa> and seeing what roadblocks you run into
115 2019-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)
116 2019-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 :)
117 2019-11-21T02:53:51  <michaelfolkson> Obviously not for everyone. But I've a got a couple of smart cookies in my study group
118 2019-11-21T02:54:48  <waxwing> michaelfolkson, the best way to go down the musig rabbit hole is probably to read the paper.
119 2019-11-21T02:54:54  <waxwing> i mean not all of it necessarily :)
120 2019-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
121 2019-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
122 2019-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
123 2019-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
124 2019-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
125 2019-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.
126 2019-11-21T02:58:26  <waxwing> i mean for certain values of 'simpler' :)
127 2019-11-21T02:59:52  <michaelfolkson> But what to recommend reading/reviewing after the blog post and after the Musig paper?
128 2019-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.
129 2019-11-21T03:00:58  <waxwing> but maybe you mean like code or something?
130 2019-11-21T03:01:03  <michaelfolkson> Yeah
131 2019-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
132 2019-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
133 2019-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
134 2019-11-21T03:02:23  <waxwing> heh
135 2019-11-21T03:02:25  <sipa> clearly they had no clue what a round in a protocol, and the necessity for it, was
136 2019-11-21T03:02:42  <waxwing> as long as you serialize them in the right order, it's secure :)
137 2019-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
138 2019-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
139 2019-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
140 2019-11-21T03:05:24  <michaelfolkson> Thanks a lot all (especially as it wasn't supposed to happen....)
141 2019-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.
142 2019-11-21T03:05:46  <aj> michaelfolkson: well, "ask questions any time" is okay too, doesn't have to be in a Q&A slot
143 2019-11-21T03:06:00  <michaelfolkson> Ok cool
144 2019-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
145 2019-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
146 2019-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.
147 2019-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"
148 2019-11-21T03:09:52  <gmaxwell> aj: for a lot of this stuff, at least for fancy uses, minor errors mean anyone can break it. :(
149 2019-11-21T03:10:14  <waxwing> my 'less helpful' is unhelpful :) but, i think there's a point there about growing complexity and fundamental principles.
150 2019-11-21T03:10:54  <waxwing> right gmaxwell nonce fragility in these sig systems is arguably kinda unacceptable. for example.
151 2019-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)
152 2019-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)
153 2019-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.
154 2019-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.
155 2019-11-21T03:24:38  *** Chris_Stewart_5 has joined ##taproot-bip-review
156 2019-11-21T03:32:27  *** michaelfolkson has quit IRC
157 2019-11-21T04:16:13  *** Chris_Stewart_5 has quit IRC
158 2019-11-21T04:26:22  *** pglazman has joined ##taproot-bip-review
159 2019-11-21T04:34:57  *** pglazman has quit IRC
160 2019-11-21T04:34:57  *** rottensox has quit IRC
161 2019-11-21T04:52:13  *** ZmnSCPxj has joined ##taproot-bip-review
162 2019-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?
163 2019-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
164 2019-11-21T04:54:50  <ZmnSCPxj> And at least discourage roll-your-own
165 2019-11-21T04:55:16  *** ZmnSCPxj has quit IRC
166 2019-11-21T05:05:26  <gmaxwell> the bip would probably just end up being a transliteration of the code.
167 2019-11-21T05:05:36  <gmaxwell> like getting it right is a billion and one tiny detals.
168 2019-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.
169 2019-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.
170 2019-11-21T05:12:28  <gmaxwell> or the existance of hardware wallets without screens.
171 2019-11-21T07:35:56  *** molz has quit IRC
172 2019-11-21T07:37:34  *** ZmnSCPxj has joined ##taproot-bip-review
173 2019-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)?
174 2019-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
175 2019-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
176 2019-11-21T07:41:49  <gmaxwell> ZmnSCPxj: web assembly + that clang compiler? :P
177 2019-11-21T07:42:16  <ZmnSCPxj> Does that work on-server in NodeJS?
178 2019-11-21T07:43:03  <gmaxwell> Apparently. (though server nodejs can call C)
179 2019-11-21T07:43:33  <ZmnSCPxj> yes, looks like it
180 2019-11-21T07:44:05  <gmaxwell> I think someone writing a spec document would be useful, but less useful than implementing it.
181 2019-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?
182 2019-11-21T08:09:45  *** jonatack has joined ##taproot-bip-review
183 2019-11-21T08:16:59  *** ZmnSCPxj has quit IRC
184 2019-11-21T08:33:06  *** jonatack_ has joined ##taproot-bip-review
185 2019-11-21T08:36:29  *** jonatack has quit IRC
186 2019-11-21T09:13:57  *** andytoshi has quit IRC
187 2019-11-21T10:52:24  *** Guest61 has quit IRC
188 2019-11-21T10:57:38  *** tecnovert has quit IRC
189 2019-11-21T11:00:03  *** tecnovert has joined ##taproot-bip-review
190 2019-11-21T11:08:17  *** jonatack_ has quit IRC
191 2019-11-21T11:32:49  *** orfeas has joined ##taproot-bip-review
192 2019-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.
193 2019-11-21T11:49:33  <waxwing> but i could be wrong.
194 2019-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.
195 2019-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
196 2019-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
197 2019-11-21T11:52:46  *** Chris_Stewart_5 has joined ##taproot-bip-review
198 2019-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.
199 2019-11-21T11:53:45  <ZmnSCPxj_> KOSK == ?
200 2019-11-21T11:54:10  *** dr-orlovsky has joined ##taproot-bip-review
201 2019-11-21T11:54:20  <waxwing> 'knowledge of secret key' ; but it's new to me also :)
202 2019-11-21T11:54:40  <waxwing> sorry 'restricted to concurrent' i meant restricted to  serial, duh
203 2019-11-21T11:56:22  <waxwing> oh nice diagram nickler thanks
204 2019-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.
205 2019-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.
206 2019-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
207 2019-11-21T11:58:51  <waxwing> because there are many ways to sum to that sum
208 2019-11-21T11:59:01  <waxwing> instead you have to freeze/bind each *individual* element.
209 2019-11-21T11:59:50  <waxwing> (this is really not a correct summary of the whole situation, but i feel like it gives some clue)
210 2019-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)
211 2019-11-21T13:11:52  <ZmnSCPxj_> thank you nickler and waxwing, this helps clarify the issue and it seems my understanding is mostly on track
212 2019-11-21T13:36:56  *** HighOnBtc has joined ##taproot-bip-review
213 2019-11-21T13:45:27  *** Chris_Stewart_5 has quit IRC
214 2019-11-21T14:00:23  *** Chris_Stewart_5 has joined ##taproot-bip-review
215 2019-11-21T14:12:45  *** andytoshi has joined ##taproot-bip-review
216 2019-11-21T14:12:45  *** andytoshi has joined ##taproot-bip-review
217 2019-11-21T14:24:12  *** shesek has quit IRC
218 2019-11-21T14:24:36  *** shesek has joined ##taproot-bip-review
219 2019-11-21T14:33:06  *** ZmnSCPxj_ has quit IRC
220 2019-11-21T14:34:02  *** ZmnSCPxj_ has joined ##taproot-bip-review
221 2019-11-21T14:35:00  *** davterra has quit IRC
222 2019-11-21T14:41:38  *** davterra has joined ##taproot-bip-review
223 2019-11-21T15:15:20  *** andytoshi has quit IRC
224 2019-11-21T15:25:24  *** midnight is now known as midnightmagic
225 2019-11-21T15:26:16  *** midnightmagic is now known as midnight
226 2019-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?
227 2019-11-21T16:58:47  <nickler> signing the same message with different nonces is fine, the issue would be different messages with the same nonce
228 2019-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
229 2019-11-21T17:00:37  <devrandom> got it, thank you
230 2019-11-21T17:43:43  *** orfeas has quit IRC
231 2019-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
232 2019-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
233 2019-11-21T18:08:01  *** jonatack_ has joined ##taproot-bip-review
234 2019-11-21T18:08:03  <sipa> dr-orlovsky: the bip-taproot tweaking commits to the internal public key
235 2019-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?
236 2019-11-21T18:09:37  <sipa> sure
237 2019-11-21T18:10:00  <dr-orlovsky> thanks
238 2019-11-21T18:15:27  *** rottensox has joined ##taproot-bip-review
239 2019-11-21T18:15:56  *** andrewtoth has joined ##taproot-bip-review
240 2019-11-21T18:29:38  *** jonatack_ has quit IRC
241 2019-11-21T18:29:52  *** jonatack has joined ##taproot-bip-review
242 2019-11-21T19:32:25  *** jonatack has quit IRC
243 2019-11-21T19:52:12  *** mol has joined ##taproot-bip-review
244 2019-11-21T19:57:40  *** Chris_Stewart_5 has quit IRC
245 2019-11-21T20:23:04  <devrandom> has anybody looked into the applicability of a MuSig-like scheme to the Lightning protocol?
246 2019-11-21T20:26:26  *** andrewtoth has quit IRC
247 2019-11-21T20:26:26  *** mryandao has quit IRC
248 2019-11-21T20:26:26  *** afk11 has quit IRC
249 2019-11-21T20:26:26  *** sipa has quit IRC
250 2019-11-21T20:28:24  <instagibbs_> yes
251 2019-11-21T20:28:30  <instagibbs_> nickler might have something written down or resources
252 2019-11-21T20:34:15  *** mryandao has joined ##taproot-bip-review
253 2019-11-21T20:36:55  *** afk11 has joined ##taproot-bip-review
254 2019-11-21T20:42:01  *** jonatack has joined ##taproot-bip-review
255 2019-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
256 2019-11-21T20:43:55  *** sipa has joined ##taproot-bip-review
257 2019-11-21T20:55:04  *** andrewtoth has joined ##taproot-bip-review
258 2019-11-21T21:04:56  *** dr-orlovsky has quit IRC
259 2019-11-21T21:05:35  *** dr-orlovsky has joined ##taproot-bip-review
260 2019-11-21T21:09:06  *** justinmoon_ has joined ##taproot-bip-review
261 2019-11-21T21:09:37  *** jkczyz_ has joined ##taproot-bip-review
262 2019-11-21T21:10:10  *** waxwing_ has joined ##taproot-bip-review
263 2019-11-21T21:10:23  *** andrewtoth_ has joined ##taproot-bip-review
264 2019-11-21T21:11:48  *** andrewtoth has quit IRC
265 2019-11-21T21:12:18  *** justinmoon has quit IRC
266 2019-11-21T21:12:19  *** waxwing has quit IRC
267 2019-11-21T21:12:19  *** jkczyz has quit IRC
268 2019-11-21T21:16:56  *** andrewtoth_ has quit IRC
269 2019-11-21T21:32:39  *** Chris_Stewart_5 has joined ##taproot-bip-review
270 2019-11-21T21:44:14  *** waxwing_ is now known as waxwing
271 2019-11-21T21:44:28  *** waxwing has joined ##taproot-bip-review
272 2019-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
273 2019-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
274 2019-11-21T22:00:38  *** andrewtoth_ has joined ##taproot-bip-review
275 2019-11-21T22:54:26  *** Chris_Stewart_5 has quit IRC
276 2019-11-21T23:41:18  *** HighOnBtc has quit IRC