14:42:08 <sarang> suraeNoether: let me know when you're available to briefly chat about multisig security for the newer sublinear transaction protocols
14:42:24 <sarang> I want to confirm a few things about honest-but-curious MPC
19:56:15 <sarang> Here is an informal description of how Triptych multisig could work: https://github.com/SarangNoether/skunkworks/blob/inverse-mpc/triptych-mpc.md
19:57:10 <real_or_random> that was quick!
20:00:03 <moneromooo> They grind quickly *and* fine.
20:04:58 <sarang> real_or_random: I haven't formally analyzed it yet, FWIW
20:05:08 <sarang> It _appears_ fine assuming honest-but-curious players
20:05:18 <real_or_random> :D
20:05:44 <sarang> A similar technique should work (or not work...) for RCT3 too
20:06:43 <sarang> I'll write that up shortly
20:07:24 <real_or_random> this reminds me that I wanted to work on making the bulletproof MPC secure against fully malicious co-provers
20:07:34 <sarang> Ah, nice!
20:07:36 <real_or_random> without doubling the number of rounds
20:07:47 <sarang> That would be even nicer!
20:08:15 <sarang> You could perhaps argue that for some multisig situations, honest-but-curious is an acceptable risk
20:08:52 <real_or_random> (not saying I have a solution but some vague ideas. I think the underlying problem is very similar to the problems in MuSig, and why you need the commitment round there)
20:09:15 <sarang> I'll be very interested to hear any ideas that you have on that
20:11:57 <moneromooo> Not sure whethere it's relevant to "honest-but-curious is an acceptable risk", but multisig is often used with people who'd steal from each other: a trade between randoms with an arbitrator in a 2/3 multisig. They wouldn't need the arbitrator if they were not gonna steal.
20:13:43 <real_or_random> sarang: yep, I should think about this. let's discuss this at some point :)
20:13:50 <sarang> For sure!
20:14:09 <real_or_random> I'm adding this to my official list of stalled research projects lol
20:14:39 <real_or_random> ah it's already on the list :D at least
20:15:42 <sarang> Yeah moneromooo what remains is to determine what risks arise (or don't) from the assumption of malicious players
20:16:02 <sarang> Adding precommitments provides stronger guarantees at the cost of communication complexity
20:16:35 <sarang> as well as avoiding the one-to-many nature of the dealer-player relationship for the proof, in favor of having all players confirm proof elements at each phase
20:16:41 <sarang> but again, adds communication complexity
20:21:07 <sarang> This is just a starting point to show that the different linking tag format isn't necessarily a showstopper for MPC
20:22:55 <real_or_random> FWIW I think honest-but-curious is mostly useless in practice
20:23:24 <real_or_random> why should  you be malicious only later? there are a few scenarios but they're a stretch
20:24:20 <real_or_random> I think hbc is mostly useful as a lower goal and a first step when constructing protocols, but not when you deploy then
20:27:07 <sarang> I was also thinking of cases like multifactor, or having the peer-to-peer data obtained
20:30:02 <sarang> The inversion MPC does include extra proofs (a range proof, for one, due to the Paillier encryption) for this reason, which I didn't include in the initial writeup or example code