1 2019-11-22T00:03:08  *** Chris_Stewart_5 has joined ##taproot-bip-review
  2 2019-11-22T00:16:59  *** jkczyz_ has quit IRC
  3 2019-11-22T00:17:47  *** jkczyz has joined ##taproot-bip-review
  4 2019-11-22T00:39:36  *** Chris_Stewart_5 has quit IRC
  5 2019-11-22T00:51:53  *** Chris_Stewart_5 has joined ##taproot-bip-review
  6 2019-11-22T01:07:42  <devrandom> mostly the former, thank you
  7 2019-11-22T01:09:32  <evoskuil> In implementing bip-taproot I've encountered what appears to be unnecessary complexity due to the ordering of the annex, control and script.
  8 2019-11-22T01:09:35  <evoskuil> https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#script-validation-rules
  9 2019-11-22T01:10:11  <evoskuil> The witness is a stack, yet these elements are at the bottom of the stack and must be conditionally removed in sequence.
 10 2019-11-22T01:10:55  <sipa> i'd say they're at the top (the later elements end up being popped first by the script)
 11 2019-11-22T01:10:59  <evoskuil> This requires either an unnecessary stack copy, or implementation of the stack as a deque (stack and queue), or complex tracking of stack limits.
 12 2019-11-22T01:11:25  <sipa> and annex, control, script are at the end
 13 2019-11-22T01:11:40  <evoskuil> sipa: so is this just my misterpretation of the wording?
 14 2019-11-22T01:12:15  <sipa> perhaps, i'm happy to clarify if it's unclear
 15 2019-11-22T01:12:19  <evoskuil> "last" meaning "top"?
 16 2019-11-22T01:12:41  <sipa> yes
 17 2019-11-22T01:12:53  <sipa> if you interpret it as a stack; in my mind i treat it as a vector
 18 2019-11-22T01:12:56  <evoskuil> sipa: it's not bad, but I would suggest using "top" when referring to the stack.
 19 2019-11-22T01:13:13  <evoskuil> sip: yes, my stack is a std::vector<>
 20 2019-11-22T01:13:50  <evoskuil> sipa: but since it's always referred to as a stack, top is explicit.
 21 2019-11-22T01:13:56  <sipa> same
 22 2019-11-22T01:14:02  <sipa> here is the annex being popped off: https://github.com/sipa/bitcoin/blob/taproot/src/script/interpreter.cpp#L1831
 23 2019-11-22T01:14:13  <evoskuil> sipa: in any case I'm happy to hear.
 24 2019-11-22T01:14:18  <sipa> cool
 25 2019-11-22T01:14:33  <evoskuil> sipa: I'm committed to implementing without reference to another implementation. :)
 26 2019-11-22T01:15:04  <evoskuil> sipa: this is what I've done with most bips, including segwit - helps validate the spec.
 27 2019-11-22T01:15:38  <sipa> i absolutely agree that independent implementations are a great way to learn about unclarities in specifications
 28 2019-11-22T01:15:45  <evoskuil> sipa: though use of implementation symbols in the BIP is a bit annoying.
 29 2019-11-22T01:15:57  <sipa> but i'm scared about anyone using an independent implementation of consensus rules in production
 30 2019-11-22T01:16:27  <evoskuil> sipa: in that case you don't need a spec :).
 31 2019-11-22T01:16:41  <sipa> sure you do; it describes intended behavior
 32 2019-11-22T01:16:57  <evoskuil> sipa: sometimes... but there are undocumented behaviors, even in segwit.
 33 2019-11-22T01:16:58  <sipa> but the actual network rules are defined by the network, not a document
 34 2019-11-22T01:17:31  <evoskuil> sipa: I always walk through Core after implemeting, just to make sure.
 35 2019-11-22T01:17:52  <sipa> in any case, happy to hear comments on things that are unclear
 36 2019-11-22T01:18:59  <evoskuil> sipa: it's been very good so far. fortunately I'm aware of most of the Core impl references, so don't need to refer back.
 37 2019-11-22T01:19:14  <evoskuil> sipa: CCompactSize :/
 38 2019-11-22T01:19:54  <evoskuil> sipa: Microsoft Foundation Class names :|
 39 2019-11-22T01:20:08  <sipa> evoskuil: blame satoshi
 40 2019-11-22T01:20:20  <sipa> (we're not using that anymore in new code, though)
 41 2019-11-22T01:21:08  <evoskuil> sipa: he/she/they get all of the blame that goes with the credit. net positive I think.
 42 2019-11-22T01:21:35  <evoskuil> sipa: that's for being so responsive.
 43 2019-11-22T01:21:50  <sipa> yw
 44 2019-11-22T01:30:13  <evoskuil> sipa: a final nit on stack terminology. bip141 refers to "first push" in one case (clear enough) and also two elements on the stack, the "first one" and "second one" (unclear)...
 45 2019-11-22T01:31:44  <evoskuil> sipa: bip-taproot refers to the "last element" (unclear).
 46 2019-11-22T01:33:01  <evoskuil> sipa: but I'll leave it up to you whether you want to propose any change.
 47 2019-11-22T01:48:14  <devrandom> nickler: regarding the basepoint tweaks, would you expect that they stay pretty much the same because of linearity?
 48 2019-11-22T02:05:55  *** soju has quit IRC
 49 2019-11-22T02:11:11  *** molly has joined ##taproot-bip-review
 50 2019-11-22T02:14:16  *** mol has quit IRC
 51 2019-11-22T02:36:37  *** Chris_Stewart_5 has quit IRC
 52 2019-11-22T03:26:29  *** molz_ has joined ##taproot-bip-review
 53 2019-11-22T03:29:28  *** molly has quit IRC
 54 2019-11-22T04:31:11  *** jonatack_ has joined ##taproot-bip-review
 55 2019-11-22T04:34:17  *** jonatack has quit IRC
 56 2019-11-22T04:38:37  *** ZmnSCPxj_ has quit IRC
 57 2019-11-22T04:45:33  *** ZmnSCPxj has joined ##taproot-bip-review
 58 2019-11-22T04:46:58  <ZmnSCPxj> nickler, devrandom: Still cannot make MuSig-in-MuSig work. Suggestion from Yannick Seurin and Tim Ruffing is to use ElGamal commitments instead of hash commitments for round 1, but....
 59 2019-11-22T04:47:31  <ZmnSCPxj> A participant could delay and send an ElGamal commitment that commits to its own R contribution and subtracts also the commitments of every other participant
 60 2019-11-22T04:48:18  <ZmnSCPxj> Then when exchanging blinding factors and revealing R, that participant can delay and also subtracts the blinding factors of every other participant from its blinding factor
 61 2019-11-22T04:48:38  <ZmnSCPxj> Leading to a summed R that this lagging participant controls completely by key cancellation.
 62 2019-11-22T04:49:31  <ZmnSCPxj> And opening it up to Wagner attacks
 63 2019-11-22T04:49:58  <ZmnSCPxj> Given the KOSK suggestion from waxwing, it looks to me that participants would instead have to prove knowledge of the secret behind R.
 64 2019-11-22T04:50:07  <ZmnSCPxj> Which is easiest done by signing using R as the pubkey.
 65 2019-11-22T04:50:22  <ZmnSCPxj> So that you end up signing (singly) while signing (multiply).
 66 2019-11-22T04:50:41  <ZmnSCPxj> Which I suppose is appropriate, given that I hear you like MuSig, so I put an aggregate in your aggregate.
 67 2019-11-22T04:51:25  <sipa> yo dawg
 68 2019-11-22T04:51:43  <ZmnSCPxj> epic rap battle incoming
 69 2019-11-22T04:55:38  <aj> ZmnSCPxj: can you use pedersen commitments? so phase 1 everyone provides R+kH instead of H(R), phase 2 everyone reveals k thus revealing R (instead of directly sending R)?
 70 2019-11-22T04:56:48  <ZmnSCPxj> I think Wagnerian attack is possible by me grinding on k in that case
 71 2019-11-22T04:57:14  <ZmnSCPxj> To let me target a specific R
 72 2019-11-22T04:58:03  <ZmnSCPxj> Maybe. Yannick had a good argument against it, but it slips my limited processing power.  Need to take over some more botnets.
 73 2019-11-22T04:58:21  <aj> yeah, i'm not even sure what i'm trying to suggest, let alone how it might be attackable
 74 2019-11-22T04:58:39  <ZmnSCPxj> Because that was my initial suggestion actually, to just use Pedersen commitments.
 75 2019-11-22T05:01:17  <ZmnSCPxj> Basically with many parallel signing sessions, in round 3, I just accept your s computed from the R after I give some random k that does not decommit my own R, because I do not have my own R.
 76 2019-11-22T05:01:54  <ZmnSCPxj> But that lets me give you a bunch of e across multiple signing sessions until they sum up to an e that I want to target.  I think.
 77 2019-11-22T05:04:36  <ZmnSCPxj> When thinking "why can we not just ENGINEER the SHIT out of this?" then maybe instead of participants being allowed to give only one R, maybe allow them to give 1 o more Rs.
 78 2019-11-22T05:05:14  <ZmnSCPxj> As long as you, as a participant, give at least one R that you generated from pure randomness, then you can assure that the summed R is also pure randomness
 79 2019-11-22T05:05:46  <ZmnSCPxj> That way, a MuSig-in-MuSig would just have the inner MuSig give multiple R commitments, then each R that reveals that commitment.
 80 2019-11-22T05:06:34  <ZmnSCPxj> Which is simple, does not diverge too much from the MuSig paper, and totally leaks that a participant is actually an aggregate, but probably works.
 81 2019-11-22T05:09:11  *** davterra has quit IRC
 82 2019-11-22T05:14:04  <aj> ZmnSCPxj: right, i think i see; (R1+k1H + R2+k2H - k2H - xH) lets player 1 control what player 2 signs so should be vulnerable to wagner, and then KOSK for (R1+k1H-xH) would save you, but probably be a pain to aggregate
 83 2019-11-22T05:32:13  <ZmnSCPxj> Anyway, going back into topic: In a privacy application, have a multiparticipant set (via MuSig) that controls one or more UTXOs.
 84 2019-11-22T05:32:37  <ZmnSCPxj> For privacy, each UTXO it controls should have a different address onchain.
 85 2019-11-22T05:33:32  <ZmnSCPxj> My idea is to take the MuSig of the multiparticipants and add a tapscript to `OP_RETURN <random>`, where `<random>` is generated from a shared secret with fair contributions from each participant, plus a UTXO index.
 86 2019-11-22T05:34:21  <ZmnSCPxj> This is secure, right?
 87 2019-11-22T05:35:52  <ZmnSCPxj> aj: yes, something like that
 88 2019-11-22T08:05:20  *** jonatack_ has quit IRC
 89 2019-11-22T08:05:35  *** jonatack has joined ##taproot-bip-review
 90 2019-11-22T08:52:14  *** evoskuil has quit IRC
 91 2019-11-22T08:56:28  *** Aleru has quit IRC
 92 2019-11-22T08:56:38  *** Aleru has joined ##taproot-bip-review
 93 2019-11-22T09:04:50  *** Aleru has quit IRC
 94 2019-11-22T09:05:01  *** Aleru has joined ##taproot-bip-review
 95 2019-11-22T09:33:30  *** aj has quit IRC
 96 2019-11-22T09:34:18  *** aj has joined ##taproot-bip-review
 97 2019-11-22T10:04:03  *** rottensox has quit IRC
 98 2019-11-22T10:27:16  <nickler> ZmnSCPxj: Interesting attack. I hadn't thought about it before. Seems like proving knowledge of the commitment opening should work in principle, but aggregating them (interactively) seems challenging (what aj said).
 99 2019-11-22T10:27:20  <nickler> The non-transparent variant should be straight forward and is definitely something we want to support in libsecp-zkp.
100 2019-11-22T10:29:09  <ZmnSCPxj> non-transparent variant...?
101 2019-11-22T10:30:15  <ZmnSCPxj> If you refer to the "let any participant give any number of `R` commitments and `R` points", is that not "transparent" since it gives an upper bound to the number of members in the aggregate?
102 2019-11-22T10:30:37  <nickler> non-transparent: where the "outer" musig participants are aware that there are some already MuSig-combined participants
103 2019-11-22T10:31:11  <ZmnSCPxj> okay, I suppose a disagreement on the exact meaning of "transparent"
104 2019-11-22T10:31:29  <ZmnSCPxj> Is that distinct from my proposal to just allow multiple `R`s?
105 2019-11-22T10:31:44  <nickler> no, that's it
106 2019-11-22T10:31:55  <ZmnSCPxj> yes, it seems straightforward.
107 2019-11-22T10:32:51  <ZmnSCPxj> Am writing a lengthy article for bitcoin-dev regarding composable MuSig as well as the various variants I considered along the way, mostly just to promote this multiple-`R` extension to the original MuSig protocol.
108 2019-11-22T10:34:03  <nickler> cool, perhaps you come up with a better name than transparent/non-transparent then :)
109 2019-11-22T10:37:50  <ZmnSCPxj> multi-`R`?
110 2019-11-22T10:41:34  <nickler> not bad
111 2019-11-22T10:45:36  <ZmnSCPxj> Multi-`R`: Random R Redundancy Requirement: Revoking Remote R Repression
112 2019-11-22T10:46:59  <nickler> ZmnSCPxj: re your privacy application, that seems to work if there's no script spends (otherwise the internal keys will be linkable). If there are no script spends you can directly taproot tweak with <random> without having to add an explicit OP_RETURN tapscript.
113 2019-11-22T10:47:37  <gmaxwell> FWIW, I knew what transparent ment. :P
114 2019-11-22T10:48:09  <nickler> Also not clear why <random> needs to have fair contributions because you're trusting every participant anyway for privacy (if everyone knows about their utxos).
115 2019-11-22T10:49:27  <ZmnSCPxj> I was wondering if there may be Wagnerian attacks possible here, wherein *which* `<random>` is added to *which* transaction might allow one of the participants to actively subvert the protocol and redirect funds to itself alone.
116 2019-11-22T10:49:28  *** orfeas has joined ##taproot-bip-review
117 2019-11-22T10:50:15  <ZmnSCPxj> Basically, this is a CoinJoinXT, so some of the TXOs will be spent by other transactions that will themselves have aggregate-controlled UTXOs
118 2019-11-22T10:50:43  <ZmnSCPxj> the `<random>` added in a later transactions might be used to Wagner-attack earlier transaction TXOs.
119 2019-11-22T10:51:19  <ZmnSCPxj> is what I was thinking
120 2019-11-22T10:51:47  <ZmnSCPxj> Wow, Wagner attack is so dangerous
121 2019-11-22T10:53:09  <nickler> ah, I don't know about the specifics of CoinJoinXT, but controlling a taproot tweak doesn't enable any (known) wagner attack on taproot outputs.
122 2019-11-22T10:54:45  <ZmnSCPxj> Yes, but what about transaction outputs that spend other transaction outputs? I admit I have not thought very clearly here, and decided to just be as paranoid as possible and force fair contribution of `<random>`
123 2019-11-22T10:56:10  <nickler> transaction outputs that spend transaction outputs?
124 2019-11-22T10:56:27  <ZmnSCPxj> yes
125 2019-11-22T10:57:08  <ZmnSCPxj> transaction outputs of transactions that spend other transactions outputs --- I mean.
126 2019-11-22T10:57:24  <ZmnSCPxj> Hmm
127 2019-11-22T10:57:31  <ZmnSCPxj> However, that is a message
128 2019-11-22T10:57:34  <nickler> ah
129 2019-11-22T10:58:11  <ZmnSCPxj> And supposedly if we do the MuSig properly and select `h(R)` and `R` *after* the message is selected, it should be OK, right?
130 2019-11-22T10:59:58  <nickler> It should be okay. If there was a wagner attack if contributions to random weren't fairly that would be quite surprising. I guess I need to read up on coinjoinxt. bbl
131 2019-11-22T11:01:11  <ZmnSCPxj> Eh.... belt-and-suspenders, I guess
132 2019-11-22T11:03:03  *** molly has joined ##taproot-bip-review
133 2019-11-22T11:05:29  <orfeas> Hi all, I couldn't find where BIP66 mentions the inherent ECDSA vulnerability (which it should according to the "Motivation" of bip-schnorr). Can someone point me to that mention please?
134 2019-11-22T11:06:25  *** molz_ has quit IRC
135 2019-11-22T11:18:38  *** Chris_Stewart_5 has joined ##taproot-bip-review
136 2019-11-22T11:19:10  <gmaxwell> orfeas: BIP66 is specific to DER encoding, the malleability related implications are discussed in BIP62 (which is referenced in BIP66)
137 2019-11-22T11:19:57  <orfeas> gmaxwell: Thanks. Then why do we link to BIP66 in bip-schnorr?
138 2019-11-22T11:22:48  <gmaxwell> presumably because it got cited by someone who didn't go read BIP66.  BIP66 itself only discusses the implementation-definedness criteria, which is also a motivation for bip-schnorr but not one the current text really discusses (though I did open an issue on that)
139 2019-11-22T11:23:09  *** ZmnSCPxj has quit IRC
140 2019-11-22T11:23:42  <gmaxwell> BIP 146 would be a better reference there.
141 2019-11-22T11:24:00  <gmaxwell> though I believe it's redundant with BIP62.
142 2019-11-22T11:24:02  <gmaxwell> too.
143 2019-11-22T11:26:23  <gmaxwell> BIP66 essentially talks about the fact that there is no guarentee that two distinct ECDSA implementations with the same curve will accept and reject exactly the same signatures.  This makes it unusable in a consensus system (without additional restrictions).
144 2019-11-22T11:27:02  <gmaxwell> (same issue exists for many other production digital signature systems, not just ECDSA)
145 2019-11-22T11:28:28  <orfeas> I just read the corresponding issue: https://github.com/sipa/bips/issues/110
146 2019-11-22T11:29:25  <orfeas> I agree that if there is a design target to have everyone reject and accept the same thing, it should be explicitly stated. and a reference to BIP66 is relevant there
147 2019-11-22T11:29:51  <orfeas> But it isn't relevant where it is now, I think
148 2019-11-22T11:30:53  <gmaxwell> ( https://github.com/sipa/bips/issues/110 )
149 2019-11-22T11:33:00  <gmaxwell> There is some context on 66 that isn't in the BIP too...  OpenSSL was, at the time, introducing an exploitable consensus vulnerablity in Bitcoin which BIP66 closed by restricting the DER encodings the software would accept.
150 2019-11-22T11:33:56  <gmaxwell> (The vulnerablity was that the set of signatures openssl accepted as valid depended on sizeof(long int) or some other typedef that differed on supported platforms)
151 2019-11-22T11:34:20  <gmaxwell> (so even though all bitcoin nodes used openssl they could be caused to fall out of consensus)
152 2019-11-22T11:34:55  <gmaxwell> So even though encoding malleability was a big thing that BIP66 helped with, it hardly got discussed in it because our main motivation was making the consensus rules independant of openssl.
153 2019-11-22T11:46:44  <waxwing> is Zmn's scheme he's describing here, on the mailing list somewhere? i feel like i have to read the initial overall idea before understanding what's been discussed in the scrollback.
154 2019-11-22T11:51:53  <orfeas> another thing: in "Implicit Y coordinates" we find "(option 2 in the previous design choice)" is there maybe a relevant link, e.g. a past commit? Or the parenthesis is mostly historical cruft that could be removed entirely?
155 2019-11-22T12:20:11  <waxwing> orfeas, it's referring to the section just above "Encoding R and public key Point P"
156 2019-11-22T12:21:54  <orfeas> that's much simpler than I thought then! Maybe rephrase it to "(option 2 in the list above)"? At least one person was confused by the current phrasing :P
157 2019-11-22T12:26:10  *** jonatack has quit IRC
158 2019-11-22T12:48:38  *** Chris_Stewart_5 has quit IRC
159 2019-11-22T13:00:29  *** Chris_Stewart_5 has joined ##taproot-bip-review
160 2019-11-22T13:44:38  *** davterra has joined ##taproot-bip-review
161 2019-11-22T14:24:20  *** shesek has quit IRC
162 2019-11-22T14:24:46  *** shesek has joined ##taproot-bip-review
163 2019-11-22T14:24:46  *** shesek has quit IRC
164 2019-11-22T14:24:46  *** shesek has joined ##taproot-bip-review
165 2019-11-22T16:21:58  *** jonatack has joined ##taproot-bip-review
166 2019-11-22T16:26:26  *** andrewtoth_ has quit IRC
167 2019-11-22T16:29:23  *** andrewtoth has joined ##taproot-bip-review
168 2019-11-22T16:31:16  *** jonatack_ has joined ##taproot-bip-review
169 2019-11-22T16:34:16  *** andrewtoth has quit IRC
170 2019-11-22T16:34:28  *** jonatack has quit IRC
171 2019-11-22T16:53:56  *** andrewtoth has joined ##taproot-bip-review
172 2019-11-22T17:08:55  *** shesek has quit IRC
173 2019-11-22T17:09:42  *** shesek has joined ##taproot-bip-review
174 2019-11-22T17:09:42  *** shesek has quit IRC
175 2019-11-22T17:09:42  *** shesek has joined ##taproot-bip-review
176 2019-11-22T17:14:17  *** shesek has quit IRC
177 2019-11-22T17:16:02  *** mol has joined ##taproot-bip-review
178 2019-11-22T17:16:49  *** shesek has joined ##taproot-bip-review
179 2019-11-22T17:16:49  *** shesek has quit IRC
180 2019-11-22T17:16:49  *** shesek has joined ##taproot-bip-review
181 2019-11-22T17:19:04  *** molly has quit IRC
182 2019-11-22T17:20:57  *** shesek has quit IRC
183 2019-11-22T17:21:09  *** andrewtoth_ has joined ##taproot-bip-review
184 2019-11-22T17:21:24  *** andrewtoth has quit IRC
185 2019-11-22T17:24:41  *** shesek has joined ##taproot-bip-review
186 2019-11-22T17:24:41  *** shesek has quit IRC
187 2019-11-22T17:24:41  *** shesek has joined ##taproot-bip-review
188 2019-11-22T17:26:52  *** mol has quit IRC
189 2019-11-22T17:29:57  *** mol has joined ##taproot-bip-review
190 2019-11-22T17:35:38  *** Chris_Stewart_5 has quit IRC
191 2019-11-22T17:41:25  *** shesek has quit IRC
192 2019-11-22T17:42:20  *** shesek has joined ##taproot-bip-review
193 2019-11-22T17:42:21  *** shesek has quit IRC
194 2019-11-22T17:42:21  *** shesek has joined ##taproot-bip-review
195 2019-11-22T17:46:50  *** shesek has quit IRC
196 2019-11-22T17:49:35  *** shesek has joined ##taproot-bip-review
197 2019-11-22T17:49:36  *** shesek has quit IRC
198 2019-11-22T17:49:36  *** shesek has joined ##taproot-bip-review
199 2019-11-22T17:53:28  *** Chris_Stewart_5 has joined ##taproot-bip-review
200 2019-11-22T17:53:38  *** shesek has quit IRC
201 2019-11-22T17:58:26  *** shesek has joined ##taproot-bip-review
202 2019-11-22T17:58:26  *** shesek has quit IRC
203 2019-11-22T17:58:26  *** shesek has joined ##taproot-bip-review
204 2019-11-22T17:59:53  <raj_149> just a quick question.. what does it mean to negate a point? In the case where is_square_y() is not true for a point, the musig_aggregate_nonce_point is negated. Is it simply reflecting the point about x axis? what field operation i can do on the y-coordinate to get the negated point?
205 2019-11-22T18:03:03  *** shesek has quit IRC
206 2019-11-22T18:06:21  *** shesek has joined ##taproot-bip-review
207 2019-11-22T18:06:21  *** shesek has quit IRC
208 2019-11-22T18:06:21  *** shesek has joined ##taproot-bip-review
209 2019-11-22T18:09:35  <sipa> raj_149: the negative of point (x,y) is simply the point (x,-y)
210 2019-11-22T18:10:06  <sipa> if you treat coordinates as integers, then negating (x,y) gives (x,p-y), where is the field size (2^256 - 2^32 - 977)
211 2019-11-22T18:11:16  *** shesek has quit IRC
212 2019-11-22T18:11:17  <raj_149> ok clear, thanks :)
213 2019-11-22T18:13:02  <raj_149> also does that mean multiplying the point with (p-1) gives the same result?
214 2019-11-22T18:14:39  *** shesek has joined ##taproot-bip-review
215 2019-11-22T18:14:39  *** shesek has quit IRC
216 2019-11-22T18:14:39  *** shesek has joined ##taproot-bip-review
217 2019-11-22T18:20:37  *** shesek has quit IRC
218 2019-11-22T18:25:10  <sipa> raj_149: no, but multiplying with (n-1) does (where n is the curve order)
219 2019-11-22T18:25:14  *** jonatack_ has quit IRC
220 2019-11-22T18:25:32  *** jonatack has joined ##taproot-bip-review
221 2019-11-22T18:25:46  *** orfeas has quit IRC
222 2019-11-22T18:26:05  *** shesek has joined ##taproot-bip-review
223 2019-11-22T18:26:06  *** shesek has quit IRC
224 2019-11-22T18:26:06  *** shesek has joined ##taproot-bip-review
225 2019-11-22T18:27:15  <raj_149> okay.. that makes sense..
226 2019-11-22T18:29:42  <sipa> raj_149: note that in general it is not true that a*(x,y) = (x,a*y); that is only the case for a=-1
227 2019-11-22T18:30:20  <sipa> but because scalars you multiply with points are modulo n, and coordinates are modulo p, the -1 outside is equal to n-1, and the -1 inside is equal to p-1
228 2019-11-22T18:30:26  *** shesek has quit IRC
229 2019-11-22T18:32:51  *** shesek has joined ##taproot-bip-review
230 2019-11-22T18:32:51  *** shesek has joined ##taproot-bip-review
231 2019-11-22T18:33:29  <raj_149> oh thats pretty neat. Is it always true that the scalars we multiply points with are modulo n? i cant multiply with m > n?
232 2019-11-22T18:34:11  <raj_149> oh right. in that case it will simply wrap back up with modulo n.
233 2019-11-22T18:36:50  <sipa> you can multiply with any integer, but multiplying with a, or a-n, or a+n, ... is all the same
234 2019-11-22T18:37:22  *** shesek has quit IRC
235 2019-11-22T18:37:37  <sipa> (ignore this if this is too much... there also exist numbers L and B such that L*(x,y) = (B*x,y))
236 2019-11-22T18:40:51  *** shesek has joined ##taproot-bip-review
237 2019-11-22T18:46:35  *** shesek has quit IRC
238 2019-11-22T18:48:57  *** shesek has joined ##taproot-bip-review
239 2019-11-22T18:48:57  *** shesek has joined ##taproot-bip-review
240 2019-11-22T18:53:24  *** shesek has quit IRC
241 2019-11-22T18:55:57  *** shesek has joined ##taproot-bip-review
242 2019-11-22T19:00:22  *** shesek has quit IRC
243 2019-11-22T19:02:56  *** shesek has joined ##taproot-bip-review
244 2019-11-22T19:02:56  *** shesek has joined ##taproot-bip-review
245 2019-11-22T19:07:49  *** shesek has quit IRC
246 2019-11-22T19:12:46  *** shesek has joined ##taproot-bip-review
247 2019-11-22T19:12:46  *** shesek has joined ##taproot-bip-review
248 2019-11-22T19:17:29  *** shesek has quit IRC
249 2019-11-22T19:22:41  *** shesek has joined ##taproot-bip-review
250 2019-11-22T19:22:41  *** shesek has joined ##taproot-bip-review
251 2019-11-22T19:27:09  *** shesek has quit IRC
252 2019-11-22T19:30:29  *** shesek has joined ##taproot-bip-review
253 2019-11-22T19:30:29  *** shesek has joined ##taproot-bip-review
254 2019-11-22T19:34:50  *** shesek has quit IRC
255 2019-11-22T19:37:29  *** shesek has joined ##taproot-bip-review
256 2019-11-22T19:37:29  *** shesek has joined ##taproot-bip-review
257 2019-11-22T19:39:21  *** jonatack has quit IRC
258 2019-11-22T19:41:37  *** shesek has quit IRC
259 2019-11-22T19:45:25  *** shesek has joined ##taproot-bip-review
260 2019-11-22T19:45:25  *** shesek has joined ##taproot-bip-review
261 2019-11-22T19:49:51  *** shesek has quit IRC
262 2019-11-22T19:52:29  *** shesek has joined ##taproot-bip-review
263 2019-11-22T19:52:29  *** shesek has joined ##taproot-bip-review
264 2019-11-22T19:56:37  *** shesek has quit IRC
265 2019-11-22T20:00:49  *** shesek has joined ##taproot-bip-review
266 2019-11-22T20:07:17  *** shesek has quit IRC
267 2019-11-22T20:10:51  *** shesek has joined ##taproot-bip-review
268 2019-11-22T20:10:51  *** shesek has joined ##taproot-bip-review
269 2019-11-22T20:15:14  *** shesek has quit IRC
270 2019-11-22T20:18:55  *** shesek has joined ##taproot-bip-review
271 2019-11-22T20:18:56  *** shesek has joined ##taproot-bip-review
272 2019-11-22T20:23:14  *** shesek has quit IRC
273 2019-11-22T20:25:46  *** shesek has joined ##taproot-bip-review
274 2019-11-22T20:25:46  *** shesek has joined ##taproot-bip-review
275 2019-11-22T20:30:28  *** shesek has quit IRC
276 2019-11-22T20:33:47  *** shesek has joined ##taproot-bip-review
277 2019-11-22T20:33:47  *** shesek has joined ##taproot-bip-review
278 2019-11-22T20:38:53  <devrandom> nickler: why is musig-in-musig relevant to Lightning?  so that the funding tx goes to a plain key?
279 2019-11-22T21:00:18  *** shesek has quit IRC
280 2019-11-22T21:04:31  *** shesek has joined ##taproot-bip-review
281 2019-11-22T21:04:31  *** shesek has joined ##taproot-bip-review
282 2019-11-22T21:08:48  *** shesek has quit IRC
283 2019-11-22T21:11:21  *** shesek has joined ##taproot-bip-review
284 2019-11-22T21:11:22  *** shesek has joined ##taproot-bip-review
285 2019-11-22T21:14:17  *** Chris_Stewart_5 has quit IRC
286 2019-11-22T21:15:54  *** shesek has quit IRC
287 2019-11-22T21:16:34  <nickler> devrandom: fundign tx should go to a plain key even without musig-in-musig in a post-schnorr world. It's only a 2-of-2. One application of musig-in-musig I was thinking of is to use a 2-of-(2-of-2) for the lightning funding.
288 2019-11-22T21:17:10  *** shesek has joined ##taproot-bip-review
289 2019-11-22T21:17:22  <nickler> so you can run different lightning implementations in parallel and both have to sign for an update (transparently, without telling the other node that you're doing that)
290 2019-11-22T21:18:11  <nickler> also ZmnSCPxj's nodelet proposal on the mailing list (which I did not look into yet)
291 2019-11-22T21:37:18  *** shesek has quit IRC
292 2019-11-22T21:41:50  *** shesek has joined ##taproot-bip-review
293 2019-11-22T21:41:51  *** shesek has joined ##taproot-bip-review
294 2019-11-22T21:43:13  *** jkczyz has quit IRC
295 2019-11-22T21:46:02  *** shesek has quit IRC
296 2019-11-22T21:48:41  *** shesek has joined ##taproot-bip-review
297 2019-11-22T21:48:41  *** shesek has joined ##taproot-bip-review
298 2019-11-22T21:53:30  *** jkczyz has joined ##taproot-bip-review
299 2019-11-22T21:53:36  *** shesek has quit IRC
300 2019-11-22T21:58:34  *** shesek has joined ##taproot-bip-review
301 2019-11-22T21:58:34  *** shesek has joined ##taproot-bip-review
302 2019-11-22T22:00:06  <devrandom> right, that's what I was also thinking in https://medium.com/@devrandom/securing-lightning-nodes-39410747734b
303 2019-11-22T22:01:31  <devrandom> nickler: but could keep the outer level a normal on-chain multisig if the nested musig is proving difficult
304 2019-11-22T22:02:53  *** shesek has quit IRC
305 2019-11-22T22:03:02  *** Chris_Stewart_5 has joined ##taproot-bip-review
306 2019-11-22T22:03:36  *** shesek has joined ##taproot-bip-review
307 2019-11-22T22:03:36  *** shesek has joined ##taproot-bip-review
308 2019-11-22T22:08:06  *** shesek has quit IRC
309 2019-11-22T22:13:25  *** shesek has joined ##taproot-bip-review
310 2019-11-22T22:13:26  *** shesek has joined ##taproot-bip-review
311 2019-11-22T22:17:38  *** shesek has quit IRC
312 2019-11-22T22:20:16  *** shesek has joined ##taproot-bip-review
313 2019-11-22T22:20:16  *** shesek has joined ##taproot-bip-review
314 2019-11-22T22:25:01  *** shesek has quit IRC
315 2019-11-22T22:30:09  *** shesek has joined ##taproot-bip-review
316 2019-11-22T22:34:17  *** shesek has quit IRC
317 2019-11-22T22:38:04  *** shesek has joined ##taproot-bip-review
318 2019-11-22T22:38:04  *** shesek has joined ##taproot-bip-review
319 2019-11-22T22:42:17  *** shesek has quit IRC
320 2019-11-22T22:45:55  *** shesek has joined ##taproot-bip-review
321 2019-11-22T23:12:57  *** Chris_Stewart_5 has quit IRC