12019-11-22T00:03:08  *** Chris_Stewart_5 has joined ##taproot-bip-review
  22019-11-22T00:16:59  *** jkczyz_ has quit IRC
  32019-11-22T00:17:47  *** jkczyz has joined ##taproot-bip-review
  42019-11-22T00:39:36  *** Chris_Stewart_5 has quit IRC
  52019-11-22T00:51:53  *** Chris_Stewart_5 has joined ##taproot-bip-review
  62019-11-22T01:07:42  <devrandom> mostly the former, thank you
  72019-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.
  82019-11-22T01:09:35  <evoskuil> https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#script-validation-rules
  92019-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.
 102019-11-22T01:10:55  <sipa> i'd say they're at the top (the later elements end up being popped first by the script)
 112019-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.
 122019-11-22T01:11:25  <sipa> and annex, control, script are at the end
 132019-11-22T01:11:40  <evoskuil> sipa: so is this just my misterpretation of the wording?
 142019-11-22T01:12:15  <sipa> perhaps, i'm happy to clarify if it's unclear
 152019-11-22T01:12:19  <evoskuil> "last" meaning "top"?
 162019-11-22T01:12:41  <sipa> yes
 172019-11-22T01:12:53  <sipa> if you interpret it as a stack; in my mind i treat it as a vector
 182019-11-22T01:12:56  <evoskuil> sipa: it's not bad, but I would suggest using "top" when referring to the stack.
 192019-11-22T01:13:13  <evoskuil> sip: yes, my stack is a std::vector<>
 202019-11-22T01:13:50  <evoskuil> sipa: but since it's always referred to as a stack, top is explicit.
 212019-11-22T01:13:56  <sipa> same
 222019-11-22T01:14:02  <sipa> here is the annex being popped off: https://github.com/sipa/bitcoin/blob/taproot/src/script/interpreter.cpp#L1831
 232019-11-22T01:14:13  <evoskuil> sipa: in any case I'm happy to hear.
 242019-11-22T01:14:18  <sipa> cool
 252019-11-22T01:14:33  <evoskuil> sipa: I'm committed to implementing without reference to another implementation. :)
 262019-11-22T01:15:04  <evoskuil> sipa: this is what I've done with most bips, including segwit - helps validate the spec.
 272019-11-22T01:15:38  <sipa> i absolutely agree that independent implementations are a great way to learn about unclarities in specifications
 282019-11-22T01:15:45  <evoskuil> sipa: though use of implementation symbols in the BIP is a bit annoying.
 292019-11-22T01:15:57  <sipa> but i'm scared about anyone using an independent implementation of consensus rules in production
 302019-11-22T01:16:27  <evoskuil> sipa: in that case you don't need a spec :).
 312019-11-22T01:16:41  <sipa> sure you do; it describes intended behavior
 322019-11-22T01:16:57  <evoskuil> sipa: sometimes... but there are undocumented behaviors, even in segwit.
 332019-11-22T01:16:58  <sipa> but the actual network rules are defined by the network, not a document
 342019-11-22T01:17:31  <evoskuil> sipa: I always walk through Core after implemeting, just to make sure.
 352019-11-22T01:17:52  <sipa> in any case, happy to hear comments on things that are unclear
 362019-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.
 372019-11-22T01:19:14  <evoskuil> sipa: CCompactSize :/
 382019-11-22T01:19:54  <evoskuil> sipa: Microsoft Foundation Class names :|
 392019-11-22T01:20:08  <sipa> evoskuil: blame satoshi
 402019-11-22T01:20:20  <sipa> (we're not using that anymore in new code, though)
 412019-11-22T01:21:08  <evoskuil> sipa: he/she/they get all of the blame that goes with the credit. net positive I think.
 422019-11-22T01:21:35  <evoskuil> sipa: that's for being so responsive.
 432019-11-22T01:21:50  <sipa> yw
 442019-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)...
 452019-11-22T01:31:44  <evoskuil> sipa: bip-taproot refers to the "last element" (unclear).
 462019-11-22T01:33:01  <evoskuil> sipa: but I'll leave it up to you whether you want to propose any change.
 472019-11-22T01:48:14  <devrandom> nickler: regarding the basepoint tweaks, would you expect that they stay pretty much the same because of linearity?
 482019-11-22T02:05:55  *** soju has quit IRC
 492019-11-22T02:11:11  *** molly has joined ##taproot-bip-review
 502019-11-22T02:14:16  *** mol has quit IRC
 512019-11-22T02:36:37  *** Chris_Stewart_5 has quit IRC
 522019-11-22T03:26:29  *** molz_ has joined ##taproot-bip-review
 532019-11-22T03:29:28  *** molly has quit IRC
 542019-11-22T04:31:11  *** jonatack_ has joined ##taproot-bip-review
 552019-11-22T04:34:17  *** jonatack has quit IRC
 562019-11-22T04:38:37  *** ZmnSCPxj_ has quit IRC
 572019-11-22T04:45:33  *** ZmnSCPxj has joined ##taproot-bip-review
 582019-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....
 592019-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
 602019-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
 612019-11-22T04:48:38  <ZmnSCPxj> Leading to a summed R that this lagging participant controls completely by key cancellation.
 622019-11-22T04:49:31  <ZmnSCPxj> And opening it up to Wagner attacks
 632019-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.
 642019-11-22T04:50:07  <ZmnSCPxj> Which is easiest done by signing using R as the pubkey.
 652019-11-22T04:50:22  <ZmnSCPxj> So that you end up signing (singly) while signing (multiply).
 662019-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.
 672019-11-22T04:51:25  <sipa> yo dawg
 682019-11-22T04:51:43  <ZmnSCPxj> epic rap battle incoming
 692019-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)?
 702019-11-22T04:56:48  <ZmnSCPxj> I think Wagnerian attack is possible by me grinding on k in that case
 712019-11-22T04:57:14  <ZmnSCPxj> To let me target a specific R
 722019-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.
 732019-11-22T04:58:21  <aj> yeah, i'm not even sure what i'm trying to suggest, let alone how it might be attackable
 742019-11-22T04:58:39  <ZmnSCPxj> Because that was my initial suggestion actually, to just use Pedersen commitments.
 752019-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.
 762019-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.
 772019-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.
 782019-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
 792019-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.
 802019-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.
 812019-11-22T05:09:11  *** davterra has quit IRC
 822019-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
 832019-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.
 842019-11-22T05:32:37  <ZmnSCPxj> For privacy, each UTXO it controls should have a different address onchain.
 852019-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.
 862019-11-22T05:34:21  <ZmnSCPxj> This is secure, right?
 872019-11-22T05:35:52  <ZmnSCPxj> aj: yes, something like that
 882019-11-22T08:05:20  *** jonatack_ has quit IRC
 892019-11-22T08:05:35  *** jonatack has joined ##taproot-bip-review
 902019-11-22T08:52:14  *** evoskuil has quit IRC
 912019-11-22T08:56:28  *** Aleru has quit IRC
 922019-11-22T08:56:38  *** Aleru has joined ##taproot-bip-review
 932019-11-22T09:04:50  *** Aleru has quit IRC
 942019-11-22T09:05:01  *** Aleru has joined ##taproot-bip-review
 952019-11-22T09:33:30  *** aj has quit IRC
 962019-11-22T09:34:18  *** aj has joined ##taproot-bip-review
 972019-11-22T10:04:03  *** rottensox has quit IRC
 982019-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).
 992019-11-22T10:27:20  <nickler> The non-transparent variant should be straight forward and is definitely something we want to support in libsecp-zkp.
1002019-11-22T10:29:09  <ZmnSCPxj> non-transparent variant...?
1012019-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?
1022019-11-22T10:30:37  <nickler> non-transparent: where the "outer" musig participants are aware that there are some already MuSig-combined participants
1032019-11-22T10:31:11  <ZmnSCPxj> okay, I suppose a disagreement on the exact meaning of "transparent"
1042019-11-22T10:31:29  <ZmnSCPxj> Is that distinct from my proposal to just allow multiple `R`s?
1052019-11-22T10:31:44  <nickler> no, that's it
1062019-11-22T10:31:55  <ZmnSCPxj> yes, it seems straightforward.
1072019-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.
1082019-11-22T10:34:03  <nickler> cool, perhaps you come up with a better name than transparent/non-transparent then :)
1092019-11-22T10:37:50  <ZmnSCPxj> multi-`R`?
1102019-11-22T10:41:34  <nickler> not bad
1112019-11-22T10:45:36  <ZmnSCPxj> Multi-`R`: Random R Redundancy Requirement: Revoking Remote R Repression
1122019-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.
1132019-11-22T10:47:37  <gmaxwell> FWIW, I knew what transparent ment. :P
1142019-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).
1152019-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.
1162019-11-22T10:49:28  *** orfeas has joined ##taproot-bip-review
1172019-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
1182019-11-22T10:50:43  <ZmnSCPxj> the `<random>` added in a later transactions might be used to Wagner-attack earlier transaction TXOs.
1192019-11-22T10:51:19  <ZmnSCPxj> is what I was thinking
1202019-11-22T10:51:47  <ZmnSCPxj> Wow, Wagner attack is so dangerous
1212019-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.
1222019-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>`
1232019-11-22T10:56:10  <nickler> transaction outputs that spend transaction outputs?
1242019-11-22T10:56:27  <ZmnSCPxj> yes
1252019-11-22T10:57:08  <ZmnSCPxj> transaction outputs of transactions that spend other transactions outputs --- I mean.
1262019-11-22T10:57:24  <ZmnSCPxj> Hmm
1272019-11-22T10:57:31  <ZmnSCPxj> However, that is a message
1282019-11-22T10:57:34  <nickler> ah
1292019-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?
1302019-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
1312019-11-22T11:01:11  <ZmnSCPxj> Eh.... belt-and-suspenders, I guess
1322019-11-22T11:03:03  *** molly has joined ##taproot-bip-review
1332019-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?
1342019-11-22T11:06:25  *** molz_ has quit IRC
1352019-11-22T11:18:38  *** Chris_Stewart_5 has joined ##taproot-bip-review
1362019-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)
1372019-11-22T11:19:57  <orfeas> gmaxwell: Thanks. Then why do we link to BIP66 in bip-schnorr?
1382019-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)
1392019-11-22T11:23:09  *** ZmnSCPxj has quit IRC
1402019-11-22T11:23:42  <gmaxwell> BIP 146 would be a better reference there.
1412019-11-22T11:24:00  <gmaxwell> though I believe it's redundant with BIP62.
1422019-11-22T11:24:02  <gmaxwell> too.
1432019-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).
1442019-11-22T11:27:02  <gmaxwell> (same issue exists for many other production digital signature systems, not just ECDSA)
1452019-11-22T11:28:28  <orfeas> I just read the corresponding issue: https://github.com/sipa/bips/issues/110
1462019-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
1472019-11-22T11:29:51  <orfeas> But it isn't relevant where it is now, I think
1482019-11-22T11:30:53  <gmaxwell> ( https://github.com/sipa/bips/issues/110 )
1492019-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.
1502019-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)
1512019-11-22T11:34:20  <gmaxwell> (so even though all bitcoin nodes used openssl they could be caused to fall out of consensus)
1522019-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.
1532019-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.
1542019-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?
1552019-11-22T12:20:11  <waxwing> orfeas, it's referring to the section just above "Encoding R and public key Point P"
1562019-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
1572019-11-22T12:26:10  *** jonatack has quit IRC
1582019-11-22T12:48:38  *** Chris_Stewart_5 has quit IRC
1592019-11-22T13:00:29  *** Chris_Stewart_5 has joined ##taproot-bip-review
1602019-11-22T13:44:38  *** davterra has joined ##taproot-bip-review
1612019-11-22T14:24:20  *** shesek has quit IRC
1622019-11-22T14:24:46  *** shesek has joined ##taproot-bip-review
1632019-11-22T14:24:46  *** shesek has quit IRC
1642019-11-22T14:24:46  *** shesek has joined ##taproot-bip-review
1652019-11-22T16:21:58  *** jonatack has joined ##taproot-bip-review
1662019-11-22T16:26:26  *** andrewtoth_ has quit IRC
1672019-11-22T16:29:23  *** andrewtoth has joined ##taproot-bip-review
1682019-11-22T16:31:16  *** jonatack_ has joined ##taproot-bip-review
1692019-11-22T16:34:16  *** andrewtoth has quit IRC
1702019-11-22T16:34:28  *** jonatack has quit IRC
1712019-11-22T16:53:56  *** andrewtoth has joined ##taproot-bip-review
1722019-11-22T17:08:55  *** shesek has quit IRC
1732019-11-22T17:09:42  *** shesek has joined ##taproot-bip-review
1742019-11-22T17:09:42  *** shesek has quit IRC
1752019-11-22T17:09:42  *** shesek has joined ##taproot-bip-review
1762019-11-22T17:14:17  *** shesek has quit IRC
1772019-11-22T17:16:02  *** mol has joined ##taproot-bip-review
1782019-11-22T17:16:49  *** shesek has joined ##taproot-bip-review
1792019-11-22T17:16:49  *** shesek has quit IRC
1802019-11-22T17:16:49  *** shesek has joined ##taproot-bip-review
1812019-11-22T17:19:04  *** molly has quit IRC
1822019-11-22T17:20:57  *** shesek has quit IRC
1832019-11-22T17:21:09  *** andrewtoth_ has joined ##taproot-bip-review
1842019-11-22T17:21:24  *** andrewtoth has quit IRC
1852019-11-22T17:24:41  *** shesek has joined ##taproot-bip-review
1862019-11-22T17:24:41  *** shesek has quit IRC
1872019-11-22T17:24:41  *** shesek has joined ##taproot-bip-review
1882019-11-22T17:26:52  *** mol has quit IRC
1892019-11-22T17:29:57  *** mol has joined ##taproot-bip-review
1902019-11-22T17:35:38  *** Chris_Stewart_5 has quit IRC
1912019-11-22T17:41:25  *** shesek has quit IRC
1922019-11-22T17:42:20  *** shesek has joined ##taproot-bip-review
1932019-11-22T17:42:21  *** shesek has quit IRC
1942019-11-22T17:42:21  *** shesek has joined ##taproot-bip-review
1952019-11-22T17:46:50  *** shesek has quit IRC
1962019-11-22T17:49:35  *** shesek has joined ##taproot-bip-review
1972019-11-22T17:49:36  *** shesek has quit IRC
1982019-11-22T17:49:36  *** shesek has joined ##taproot-bip-review
1992019-11-22T17:53:28  *** Chris_Stewart_5 has joined ##taproot-bip-review
2002019-11-22T17:53:38  *** shesek has quit IRC
2012019-11-22T17:58:26  *** shesek has joined ##taproot-bip-review
2022019-11-22T17:58:26  *** shesek has quit IRC
2032019-11-22T17:58:26  *** shesek has joined ##taproot-bip-review
2042019-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?
2052019-11-22T18:03:03  *** shesek has quit IRC
2062019-11-22T18:06:21  *** shesek has joined ##taproot-bip-review
2072019-11-22T18:06:21  *** shesek has quit IRC
2082019-11-22T18:06:21  *** shesek has joined ##taproot-bip-review
2092019-11-22T18:09:35  <sipa> raj_149: the negative of point (x,y) is simply the point (x,-y)
2102019-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)
2112019-11-22T18:11:16  *** shesek has quit IRC
2122019-11-22T18:11:17  <raj_149> ok clear, thanks :)
2132019-11-22T18:13:02  <raj_149> also does that mean multiplying the point with (p-1) gives the same result?
2142019-11-22T18:14:39  *** shesek has joined ##taproot-bip-review
2152019-11-22T18:14:39  *** shesek has quit IRC
2162019-11-22T18:14:39  *** shesek has joined ##taproot-bip-review
2172019-11-22T18:20:37  *** shesek has quit IRC
2182019-11-22T18:25:10  <sipa> raj_149: no, but multiplying with (n-1) does (where n is the curve order)
2192019-11-22T18:25:14  *** jonatack_ has quit IRC
2202019-11-22T18:25:32  *** jonatack has joined ##taproot-bip-review
2212019-11-22T18:25:46  *** orfeas has quit IRC
2222019-11-22T18:26:05  *** shesek has joined ##taproot-bip-review
2232019-11-22T18:26:06  *** shesek has quit IRC
2242019-11-22T18:26:06  *** shesek has joined ##taproot-bip-review
2252019-11-22T18:27:15  <raj_149> okay.. that makes sense..
2262019-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
2272019-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
2282019-11-22T18:30:26  *** shesek has quit IRC
2292019-11-22T18:32:51  *** shesek has joined ##taproot-bip-review
2302019-11-22T18:32:51  *** shesek has joined ##taproot-bip-review
2312019-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?
2322019-11-22T18:34:11  <raj_149> oh right. in that case it will simply wrap back up with modulo n.
2332019-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
2342019-11-22T18:37:22  *** shesek has quit IRC
2352019-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))
2362019-11-22T18:40:51  *** shesek has joined ##taproot-bip-review
2372019-11-22T18:46:35  *** shesek has quit IRC
2382019-11-22T18:48:57  *** shesek has joined ##taproot-bip-review
2392019-11-22T18:48:57  *** shesek has joined ##taproot-bip-review
2402019-11-22T18:53:24  *** shesek has quit IRC
2412019-11-22T18:55:57  *** shesek has joined ##taproot-bip-review
2422019-11-22T19:00:22  *** shesek has quit IRC
2432019-11-22T19:02:56  *** shesek has joined ##taproot-bip-review
2442019-11-22T19:02:56  *** shesek has joined ##taproot-bip-review
2452019-11-22T19:07:49  *** shesek has quit IRC
2462019-11-22T19:12:46  *** shesek has joined ##taproot-bip-review
2472019-11-22T19:12:46  *** shesek has joined ##taproot-bip-review
2482019-11-22T19:17:29  *** shesek has quit IRC
2492019-11-22T19:22:41  *** shesek has joined ##taproot-bip-review
2502019-11-22T19:22:41  *** shesek has joined ##taproot-bip-review
2512019-11-22T19:27:09  *** shesek has quit IRC
2522019-11-22T19:30:29  *** shesek has joined ##taproot-bip-review
2532019-11-22T19:30:29  *** shesek has joined ##taproot-bip-review
2542019-11-22T19:34:50  *** shesek has quit IRC
2552019-11-22T19:37:29  *** shesek has joined ##taproot-bip-review
2562019-11-22T19:37:29  *** shesek has joined ##taproot-bip-review
2572019-11-22T19:39:21  *** jonatack has quit IRC
2582019-11-22T19:41:37  *** shesek has quit IRC
2592019-11-22T19:45:25  *** shesek has joined ##taproot-bip-review
2602019-11-22T19:45:25  *** shesek has joined ##taproot-bip-review
2612019-11-22T19:49:51  *** shesek has quit IRC
2622019-11-22T19:52:29  *** shesek has joined ##taproot-bip-review
2632019-11-22T19:52:29  *** shesek has joined ##taproot-bip-review
2642019-11-22T19:56:37  *** shesek has quit IRC
2652019-11-22T20:00:49  *** shesek has joined ##taproot-bip-review
2662019-11-22T20:07:17  *** shesek has quit IRC
2672019-11-22T20:10:51  *** shesek has joined ##taproot-bip-review
2682019-11-22T20:10:51  *** shesek has joined ##taproot-bip-review
2692019-11-22T20:15:14  *** shesek has quit IRC
2702019-11-22T20:18:55  *** shesek has joined ##taproot-bip-review
2712019-11-22T20:18:56  *** shesek has joined ##taproot-bip-review
2722019-11-22T20:23:14  *** shesek has quit IRC
2732019-11-22T20:25:46  *** shesek has joined ##taproot-bip-review
2742019-11-22T20:25:46  *** shesek has joined ##taproot-bip-review
2752019-11-22T20:30:28  *** shesek has quit IRC
2762019-11-22T20:33:47  *** shesek has joined ##taproot-bip-review
2772019-11-22T20:33:47  *** shesek has joined ##taproot-bip-review
2782019-11-22T20:38:53  <devrandom> nickler: why is musig-in-musig relevant to Lightning?  so that the funding tx goes to a plain key?
2792019-11-22T21:00:18  *** shesek has quit IRC
2802019-11-22T21:04:31  *** shesek has joined ##taproot-bip-review
2812019-11-22T21:04:31  *** shesek has joined ##taproot-bip-review
2822019-11-22T21:08:48  *** shesek has quit IRC
2832019-11-22T21:11:21  *** shesek has joined ##taproot-bip-review
2842019-11-22T21:11:22  *** shesek has joined ##taproot-bip-review
2852019-11-22T21:14:17  *** Chris_Stewart_5 has quit IRC
2862019-11-22T21:15:54  *** shesek has quit IRC
2872019-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.
2882019-11-22T21:17:10  *** shesek has joined ##taproot-bip-review
2892019-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)
2902019-11-22T21:18:11  <nickler> also ZmnSCPxj's nodelet proposal on the mailing list (which I did not look into yet)
2912019-11-22T21:37:18  *** shesek has quit IRC
2922019-11-22T21:41:50  *** shesek has joined ##taproot-bip-review
2932019-11-22T21:41:51  *** shesek has joined ##taproot-bip-review
2942019-11-22T21:43:13  *** jkczyz has quit IRC
2952019-11-22T21:46:02  *** shesek has quit IRC
2962019-11-22T21:48:41  *** shesek has joined ##taproot-bip-review
2972019-11-22T21:48:41  *** shesek has joined ##taproot-bip-review
2982019-11-22T21:53:30  *** jkczyz has joined ##taproot-bip-review
2992019-11-22T21:53:36  *** shesek has quit IRC
3002019-11-22T21:58:34  *** shesek has joined ##taproot-bip-review
3012019-11-22T21:58:34  *** shesek has joined ##taproot-bip-review
3022019-11-22T22:00:06  <devrandom> right, that's what I was also thinking in https://medium.com/@devrandom/securing-lightning-nodes-39410747734b
3032019-11-22T22:01:31  <devrandom> nickler: but could keep the outer level a normal on-chain multisig if the nested musig is proving difficult
3042019-11-22T22:02:53  *** shesek has quit IRC
3052019-11-22T22:03:02  *** Chris_Stewart_5 has joined ##taproot-bip-review
3062019-11-22T22:03:36  *** shesek has joined ##taproot-bip-review
3072019-11-22T22:03:36  *** shesek has joined ##taproot-bip-review
3082019-11-22T22:08:06  *** shesek has quit IRC
3092019-11-22T22:13:25  *** shesek has joined ##taproot-bip-review
3102019-11-22T22:13:26  *** shesek has joined ##taproot-bip-review
3112019-11-22T22:17:38  *** shesek has quit IRC
3122019-11-22T22:20:16  *** shesek has joined ##taproot-bip-review
3132019-11-22T22:20:16  *** shesek has joined ##taproot-bip-review
3142019-11-22T22:25:01  *** shesek has quit IRC
3152019-11-22T22:30:09  *** shesek has joined ##taproot-bip-review
3162019-11-22T22:34:17  *** shesek has quit IRC
3172019-11-22T22:38:04  *** shesek has joined ##taproot-bip-review
3182019-11-22T22:38:04  *** shesek has joined ##taproot-bip-review
3192019-11-22T22:42:17  *** shesek has quit IRC
3202019-11-22T22:45:55  *** shesek has joined ##taproot-bip-review
3212019-11-22T23:12:57  *** Chris_Stewart_5 has quit IRC