--- Day changed Thu Nov 21 2019 00:09 -!- jonatack [~jon@37.166.198.203] has joined ##taproot-bip-review 00:16 -!- ZmnSCPxj [9258463b@146.88.70.59] has quit [Ping timeout: 260 seconds] 00:33 -!- jonatack_ [~jon@37.164.255.47] has joined ##taproot-bip-review 00:36 -!- jonatack [~jon@37.166.198.203] has quit [Ping timeout: 276 seconds] 01:13 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 265 seconds] 02:52 -!- Guest61 [~textual@91.240.140.128] has quit [Quit: Textual IRC Client: www.textualapp.com] 02:57 -!- tecnovert [~user@64.34.219.27] has quit [Ping timeout: 240 seconds] 03:00 -!- tecnovert [~user@mail.tecnovert.net] has joined ##taproot-bip-review 03:08 -!- jonatack_ [~jon@37.164.255.47] has quit [Ping timeout: 240 seconds] 03:32 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has joined ##taproot-bip-review 03:49 < 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. 03:49 < waxwing> but i could be wrong. 03:50 < 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. 03:51 < 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 03:52 < 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 03:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 03:52 < 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. 03:53 < ZmnSCPxj_> KOSK == ? 03:54 -!- dr-orlovsky [~dr-orlovs@91.240.140.128] has joined ##taproot-bip-review 03:54 < waxwing> 'knowledge of secret key' ; but it's new to me also :) 03:54 < waxwing> sorry 'restricted to concurrent' i meant restricted to serial, duh 03:56 < waxwing> oh nice diagram nickler thanks 03:58 < 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. 03:58 < 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. 03:58 < 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 03:58 < waxwing> because there are many ways to sum to that sum 03:59 < waxwing> instead you have to freeze/bind each *individual* element. 03:59 < waxwing> (this is really not a correct summary of the whole situation, but i feel like it gives some clue) 04:12 < 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) 05:11 < ZmnSCPxj_> thank you nickler and waxwing, this helps clarify the issue and it seems my understanding is mostly on track 05:36 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review 05:45 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 06:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 06:12 -!- andytoshi [~apoelstra@wpsoftware.net] has joined ##taproot-bip-review 06:12 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host] 06:12 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review 06:24 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 06:24 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 06:33 -!- ZmnSCPxj_ [~ZmnSCPxj@180.190.33.230] has quit [Read error: Connection reset by peer] 06:34 -!- ZmnSCPxj_ [~ZmnSCPxj@180.190.33.172] has joined ##taproot-bip-review 06:35 -!- davterra [~dulyNoded@195.242.213.120] has quit [Ping timeout: 252 seconds] 06:41 -!- davterra [~dulyNoded@37.120.137.166] has joined ##taproot-bip-review 07:15 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 252 seconds] 07:25 -!- midnight is now known as midnightmagic 07:26 -!- midnightmagic is now known as midnight 08:56 < 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? 08:58 < nickler> signing the same message with different nonces is fine, the issue would be different messages with the same nonce 08:59 < 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 09:00 < devrandom> got it, thank you 09:43 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has quit [Remote host closed the connection] 10:04 < 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 10:04 < 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 10:08 -!- jonatack_ [~jon@37.166.3.222] has joined ##taproot-bip-review 10:08 < sipa> dr-orlovsky: the bip-taproot tweaking commits to the internal public key 10:09 < dr-orlovsky> so the internal pubkey can be tweaked itself, i.e. for instance represent Alice+Bob pubkeys + some tweak factor external to taproot? 10:09 < sipa> sure 10:10 < dr-orlovsky> thanks 10:15 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 10:15 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 10:29 -!- jonatack_ [~jon@37.166.3.222] has quit [Quit: jonatack_] 10:29 -!- jonatack [~jon@37.166.3.222] has joined ##taproot-bip-review 11:32 -!- jonatack [~jon@37.166.3.222] has quit [Read error: Connection reset by peer] 11:52 -!- mol [~molly@unaffiliated/molly] has joined ##taproot-bip-review 11:57 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 12:23 < devrandom> has anybody looked into the applicability of a MuSig-like scheme to the Lightning protocol? 12:26 -!- Netsplit *.net <-> *.split quits: afk11, andrewtoth, mryandao, sipa 12:28 < instagibbs_> yes 12:28 < instagibbs_> nickler might have something written down or resources 12:34 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review 12:36 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review 12:42 -!- jonatack [~jon@37.166.3.222] has joined ##taproot-bip-review 12:42 < devrandom> very interested in that - would put actual math behind the multi-signer aspect of https://medium.com/@devrandom/securing-lightning-nodes-39410747734b 12:43 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review 12:55 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 13:05 -!- dr-orlovsky [~dr-orlovs@91.240.140.128] has quit [Read error: Connection reset by peer] 13:05 -!- dr-orlovsky [~dr-orlovs@91.240.140.128] has joined ##taproot-bip-review 13:09 -!- justinmoon_ [~quassel@157.245.122.126] has joined ##taproot-bip-review 13:09 -!- jkczyz_ [~jkczyz@135.84.132.250] has joined ##taproot-bip-review 13:10 -!- waxwing_ [~waxwing@193.29.57.116] has joined ##taproot-bip-review 13:10 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 13:11 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 13:12 -!- justinmoon [~quassel@157.245.122.126] has quit [Quit: No Ping reply in 180 seconds.] 13:12 -!- waxwing [~waxwing@unaffiliated/waxwing] has quit [Ping timeout: 240 seconds] 13:12 -!- jkczyz [~jkczyz@135.84.132.250] has quit [Remote host closed the connection] 13:16 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 13:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 13:44 -!- waxwing_ is now known as waxwing 13:44 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host] 13:44 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined ##taproot-bip-review 13:46 < 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 13:47 < nickler> if you're asking about splitting up your lightning keys, you probably want the nested musig scheme that ZmnSCPxj_ mentioned 14:00 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 14:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 15:41 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Quit: Leaving] 16:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 16:16 -!- jkczyz_ [~jkczyz@135.84.132.250] has quit [Quit: leaving] 16:17 -!- jkczyz [~jkczyz@135.84.132.250] has joined ##taproot-bip-review 16:39 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 16:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 17:07 < devrandom> mostly the former, thank you 17:09 < evoskuil> In implementing bip-taproot I've encountered what appears to be unnecessary complexity due to the ordering of the annex, control and script. 17:09 < evoskuil> https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#script-validation-rules 17:10 < evoskuil> The witness is a stack, yet these elements are at the bottom of the stack and must be conditionally removed in sequence. 17:10 < sipa> i'd say they're at the top (the later elements end up being popped first by the script) 17:10 < 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. 17:11 < sipa> and annex, control, script are at the end 17:11 < evoskuil> sipa: so is this just my misterpretation of the wording? 17:12 < sipa> perhaps, i'm happy to clarify if it's unclear 17:12 < evoskuil> "last" meaning "top"? 17:12 < sipa> yes 17:12 < sipa> if you interpret it as a stack; in my mind i treat it as a vector 17:12 < evoskuil> sipa: it's not bad, but I would suggest using "top" when referring to the stack. 17:13 < evoskuil> sip: yes, my stack is a std::vector<> 17:13 < evoskuil> sipa: but since it's always referred to as a stack, top is explicit. 17:13 < sipa> same 17:14 < sipa> here is the annex being popped off: https://github.com/sipa/bitcoin/blob/taproot/src/script/interpreter.cpp#L1831 17:14 < evoskuil> sipa: in any case I'm happy to hear. 17:14 < sipa> cool 17:14 < evoskuil> sipa: I'm committed to implementing without reference to another implementation. :) 17:15 < evoskuil> sipa: this is what I've done with most bips, including segwit - helps validate the spec. 17:15 < sipa> i absolutely agree that independent implementations are a great way to learn about unclarities in specifications 17:15 < evoskuil> sipa: though use of implementation symbols in the BIP is a bit annoying. 17:15 < sipa> but i'm scared about anyone using an independent implementation of consensus rules in production 17:16 < evoskuil> sipa: in that case you don't need a spec :). 17:16 < sipa> sure you do; it describes intended behavior 17:16 < evoskuil> sipa: sometimes... but there are undocumented behaviors, even in segwit. 17:16 < sipa> but the actual network rules are defined by the network, not a document 17:17 < evoskuil> sipa: I always walk through Core after implemeting, just to make sure. 17:17 < sipa> in any case, happy to hear comments on things that are unclear 17:18 < 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. 17:19 < evoskuil> sipa: CCompactSize :/ 17:19 < evoskuil> sipa: Microsoft Foundation Class names :| 17:20 < sipa> evoskuil: blame satoshi 17:20 < sipa> (we're not using that anymore in new code, though) 17:21 < evoskuil> sipa: he/she/they get all of the blame that goes with the credit. net positive I think. 17:21 < evoskuil> sipa: that's for being so responsive. 17:21 < sipa> yw 17:30 < 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)... 17:31 < evoskuil> sipa: bip-taproot refers to the "last element" (unclear). 17:33 < evoskuil> sipa: but I'll leave it up to you whether you want to propose any change. 17:48 < devrandom> nickler: regarding the basepoint tweaks, would you expect that they stay pretty much the same because of linearity? 18:05 -!- soju [uid403160@gateway/web/irccloud.com/x-qqvgocvrdemjdsjf] has quit [Quit: Connection closed for inactivity] 18:11 -!- molly [~molly@unaffiliated/molly] has joined ##taproot-bip-review 18:14 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 18:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 19:26 -!- molz_ [~molly@unaffiliated/molly] has joined ##taproot-bip-review 19:29 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 245 seconds] 20:31 -!- jonatack_ [~jon@37.173.226.226] has joined ##taproot-bip-review 20:34 -!- jonatack [~jon@37.166.3.222] has quit [Ping timeout: 240 seconds] 20:38 -!- ZmnSCPxj_ [~ZmnSCPxj@180.190.33.172] has quit [Quit: ZmnSCPxj_] 20:45 -!- ZmnSCPxj [9258463b@146.88.70.59] has joined ##taproot-bip-review 20:46 < 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.... 20:47 < 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 20:48 < 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 20:48 < ZmnSCPxj> Leading to a summed R that this lagging participant controls completely by key cancellation. 20:49 < ZmnSCPxj> And opening it up to Wagner attacks 20:49 < ZmnSCPxj> Given the KOSK suggestion from waxwing, it looks to me that participants would instead have to prove knowledge of the secret behind R. 20:50 < ZmnSCPxj> Which is easiest done by signing using R as the pubkey. 20:50 < ZmnSCPxj> So that you end up signing (singly) while signing (multiply). 20:50 < ZmnSCPxj> Which I suppose is appropriate, given that I hear you like MuSig, so I put an aggregate in your aggregate. 20:51 < sipa> yo dawg 20:51 < ZmnSCPxj> epic rap battle incoming 20:55 <@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)? 20:56 < ZmnSCPxj> I think Wagnerian attack is possible by me grinding on k in that case 20:57 < ZmnSCPxj> To let me target a specific R 20:58 < ZmnSCPxj> Maybe. Yannick had a good argument against it, but it slips my limited processing power. Need to take over some more botnets. 20:58 <@aj> yeah, i'm not even sure what i'm trying to suggest, let alone how it might be attackable 20:58 < ZmnSCPxj> Because that was my initial suggestion actually, to just use Pedersen commitments. 21:01 < 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. 21:01 < 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. 21:04 < 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. 21:05 < 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 21:05 < ZmnSCPxj> That way, a MuSig-in-MuSig would just have the inner MuSig give multiple R commitments, then each R that reveals that commitment. 21:06 < 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. 21:09 -!- davterra [~dulyNoded@37.120.137.166] has quit [Quit: Leaving] 21:14 <@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 21:32 < ZmnSCPxj> Anyway, going back into topic: In a privacy application, have a multiparticipant set (via MuSig) that controls one or more UTXOs. 21:32 < ZmnSCPxj> For privacy, each UTXO it controls should have a different address onchain. 21:33 < ZmnSCPxj> My idea is to take the MuSig of the multiparticipants and add a tapscript to `OP_RETURN `, where `` is generated from a shared secret with fair contributions from each participant, plus a UTXO index. 21:34 < ZmnSCPxj> This is secure, right? 21:35 < ZmnSCPxj> aj: yes, something like that