06:50:54 <lawrenceyan> Zero Knowledge from Multi-Party Computation
06:50:55 <lawrenceyan> https://www.youtube.com/watch?v=TjPkmu2JbU8
12:57:30 <Loca422> For a community that prides itself on manipulating people, you can't manage a single guy that spends most of his time in his underpants :D
15:59:12 <sgp_> ArticMine: this is the best chart I can find with performance increases https://cdn.arstechnica.net/wp-content/uploads/2020/11/CPU-performance-retrospective.mt-gen-on-gen-1440x1080.png
15:59:55 <sgp_> still, this is only for the fastest, not really "fastest for under $200", "fastest in-stock", etc
16:04:50 <binaryFate> There is a convenient measure for storage vs. price, like GB/$. Is there anything vaguely similar published but for computing power?
16:06:08 <sgp_> I'm thinking multithread passmark score / $, adjusted for inflation
16:10:49 <sgp_> meeting in 50 mins here
16:13:56 <sgp_> https://www.cpubenchmark.net/cpu_value_alltime.html#single-cpu (today) vs http://web.archive.org/web/20181003022658/https://www.cpubenchmark.net/cpu_value_alltime.html (2018-10-03)
16:19:00 <sgp_> by best interpretation of that chart is that it's closer to a ~25-50% increase in performance/price, though others may interpret differently
16:19:14 <sgp_> eg: just look at the Ryzen 5 1600 on both charts
16:19:34 <sgp_> cost $155 before, $150 today
16:29:58 <binaryFate> raw data from these 2 pages: https://docs.google.com/spreadsheets/d/1ep55Azb_mTxFOYZnb9an2y_9G014Hz3z92EFx_VyJhI/edit?usp=sharing
16:30:27 <binaryFate> not that the numbers make specific sense to me. Feel free to use/edit.
16:53:00 <sgp_> darn, google sheets doesn't support boxplots natively
17:00:30 <sgp_> .time
17:00:38 <sgp_> that doesn't work apparently anymore haha
17:00:42 <sgp_> but it is not 17 UTC
17:00:48 <sgp_> s/not/now
17:00:58 <sgp_> Monero Research Lab meeting time
17:01:09 <sgp_> Greetings
17:01:58 <sgp_> ping sarang moneromooo SerHack ArticMine binaryFate
17:02:07 <sgp_> knaccc
17:02:36 <sarang> hi
17:02:41 <sgp_> dEBRUYNE
17:02:47 <sgp_> needmoney90
17:03:10 <sgp_> it's been a while since the last meeting, hope everyone is doing okay :)
17:04:50 <sgp_> https://github.com/monero-project/meta/issues/542
17:05:05 <sgp_> I'm going to proceed and hope other people perk up
17:05:20 <sgp_> 1. Bulletproofs+ audit(s)
17:05:26 <sgp_> this is the most pressing matter
17:05:52 <sgp_> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/197
17:06:08 <sgp_> it's been 3 weeks since they opened the proposal
17:06:33 <sgp_> sarang: you had questions, were those answered sufficiently?
17:07:01 <sarang> They were! The scope is broad so it really comes down to perceived community value
17:07:17 <sgp_> in the last community meeting, they wanted to wait for a decision here before moving the CCS or not
17:07:34 <sgp_> sarang: can you expand on what you mean by "the scope is so broad"?
17:07:54 <sarang> Well they intend to do review of the preprint, review of our code, and also compare to some other implementations
17:08:01 <sarang> Which is great to have!
17:08:16 <sarang> I happen to think it's a good value, but this is not my call
17:08:32 <sgp_> which part is the most "overkill" perhaps, the comparison?
17:08:43 <sarang> I don't want to call it overkill
17:08:50 <sarang> But if we had to choose something to nix, I'd say that
17:08:56 <sgp_> understood
17:09:00 <sarang> That being said, higher assurance is always a good thing
17:09:59 <sgp_> the scope seems relatively reasonable to me since they are proposing 1 month of work
17:10:40 <sgp_> if there's value in the comparison in your opinion, it seems reasonable to include
17:11:13 <sgp_> do people feel comfortable with just this one audit, or should we also hunt down others?
17:11:48 <sarang> sgp_: I think that the value is good for the proposed cost
17:12:02 <sarang> If it had inflated the price too much, perhaps that'd be a different story
17:12:02 <sgp_> and do we generally feel comfortable in these auditors' competencies?
17:12:21 <sarang> I can't personally vouch for them, but they do have good work out there
17:12:59 <sgp_> okay, so signs point to suggesting this is moved as-is
17:13:08 <Isthmus> +1
17:13:10 <sarang> I don't have any particular qualms, FWIW
17:13:27 <Isthmus> Best case scenario, they are good team and we receive solid audit. Worst case scenario, an audit can't make things worse :- )
17:13:51 <dEBRUYNE> False sense of security is a drawback I'd argue
17:13:52 <sgp_> well, worst case they give an audit that looks good and gives undeserved confidence
17:13:56 <dEBRUYNE> (in case of a bad audit)
17:14:14 <dEBRUYNE> I'd still prefer to have a second team looking at it, even if the scope isn't that broad
17:14:20 <dEBRUYNE> Especially since we're touching delicate parts of the code
17:14:22 <sgp_> should we be looking for other auditors now, or later after reviewing the report?
17:14:31 <sarang> Perhaps having another limited-scope audit?
17:14:37 <dEBRUYNE> I'd say before
17:14:37 <sarang> Just the proposed code
17:14:41 <sgp_> I don't see this in any case being a blocker on moving the current audit
17:14:50 <dEBRUYNE> I think another 'just code' audit would be fine
17:14:50 <Isthmus> +1 sgp
17:15:09 <ErCiccione[m]> Another audit only for the code sounds like a good idea
17:15:21 <sgp_> dEBRUYNE sarang Isthmus: any recommendations on how to reach out to others for the code-only audit?
17:15:44 <sgp_> should we just cold email Quarkslab, Kudelski, etc?
17:15:47 <dEBRUYNE> Through OSTIF I guess?
17:15:50 <gingeropolous> +1 for second audit.
17:15:54 <dEBRUYNE> They acted as intermediary in the past
17:16:09 <Isthmus> Who have we engaged with previously, and would they be a good fit for this?
17:16:29 <sgp_> fwiw, the Monero Audit workgroup was unimpressed with their assistance last time
17:16:32 <hyc> we have gone thru OSTIF to the auditors
17:16:41 <dEBRUYNE> sgp_: Of OSTIF, that is?
17:16:44 <sgp_> yes
17:17:03 <dEBRUYNE> I guess reaching out through OSTIF creates a sense of goodwill, but afaik it also increases the price
17:17:05 <hyc> what were the problems? things were pretty smooth for the randomx work
17:17:19 <sgp_> 1) we probably didn't actually get a cheaper rate, 2) the conversations usually resulted in more confusion, not less
17:17:37 <sgp_> and yes they want 10%
17:17:42 <hyc> ok
17:18:16 <sgp_> sarang: do you have email contacts for everyone we have worked with in the past?
17:18:29 <sarang> I do, yes
17:19:11 <dEBRUYNE> To maintain proper relations I think it would be better to consult OSTIF, but that's my personal opinion
17:19:13 <sgp_> okay, anyone against starting there by contacting them with our desired project and scope? sarang I can handle more of the email communication to save you time
17:19:39 <gingeropolous> and I thought ostif was necessary because the auditors have to work with some corporate entity of somekind
17:20:40 <sgp_> gingeropolous: I'm not sure, if they need an entity, we can reconsider
17:20:51 <dEBRUYNE> I think that's mostly for tax reasons, not sure
17:21:12 <sgp_> tax reasons would be for the benefit of the donors
17:21:34 <gingeropolous> k. but yeah, thats a good starting point.
17:21:46 <sgp_> okay, it's my recommendation we start there
17:23:13 <sgp_> any other comments on this topic?
17:23:29 <sgp_> in summary: move the CCS, and then look for a second, narrower audit
17:23:37 <sarang> Cool
17:23:47 <sarang> We can specifically limit the code scope
17:24:21 <sgp_> sarang: please contact me after so we can get the emails out
17:24:38 <sgp_> if anyone wants to help with the audit workgroup, please DM me
17:24:47 <sarang> can do
17:24:53 <sgp_> okay, next topic
17:25:03 <sgp_> Triptych / Arcturus
17:25:23 <sgp_> first important question on my end:
17:25:56 <sgp_> is Arcturus out? is there anything that could change/happen to make us feel comfortable with this?
17:27:33 <sarang> Well, there is a Rust implementation, which is pretty great
17:27:40 <sarang> But AFAIK no other review
17:27:52 <sgp_> (I'm afk for a few, emergency sorry)
17:28:21 <dEBRUYNE> Not sure what is withholding us from starting to work on implementing Triptych
17:28:42 <dEBRUYNE> I think people already reconciled the fact that multisig would require a bit more of a complex implementation
17:30:31 <Isthmus> gl sgp
17:31:34 <Isthmus> @sarang is the rust implementation public?
17:31:58 * Isthmus wants to poke through the repo
17:31:59 <sarang> It is!
17:32:21 <sarang> https://github.com/cargodog/arcturus
17:32:25 <sgp_> half back
17:32:39 <Isthmus> Thanks @sarang
17:32:40 <sgp_> is there any way we would run with something like this though?
17:32:48 <sgp_> there's that one assumption
17:33:17 <sarang> Arcturus is inherently riskier, given its novel assumption
17:33:17 <Isthmus> Oh yea, what's the non-standard assumption? I don't quite recall
17:33:32 <sgp_> how can we reduce risk?
17:33:38 <sgp_> or is that not really possible
17:34:04 <sarang> Time and solid peer review
17:34:14 <dEBRUYNE> A break would have pretty catastrophic ramifications
17:34:17 <sarang> But "review" of an assumption is much different than review of an implementation
17:34:22 <sarang> correct
17:34:23 <dEBRUYNE> I argue it would be prudent to 'play it safe' and opt for Triptych
17:34:35 <gingeropolous> aye
17:34:50 <dEBRUYNE> The differences are not large enough to warrant choosing an implementation that relies on a novel assumption
17:34:58 <gingeropolous> double aye
17:35:42 <sgp_> is anyone here interested in arctutus at all then
17:35:47 <sgp_> or should we stop talking about it
17:36:06 <sgp_> personally, I would feel okay with a really good review of it
17:36:23 <ArticMine> Sorry I am late. My take on Arcturus is that the assumption risk will take time. So it can be implemented after Triptych
17:36:58 <Isthmus> That all seems reasonable
17:37:07 * Isthmus nods in general agreement
17:37:19 <sgp_> okay, anyone not in favor of focusing entirely on triptych for now?
17:37:56 <moneromooo> Do those two share most code ?
17:38:08 <sarang> The structure is similar
17:38:09 <sgp_> sarang: ^
17:38:26 <sarang> But there are significant internal differences still
17:38:51 <sgp_> for the record, who is for focusing entirely on triptych
17:39:03 <ArticMine> I am
17:39:30 <sethsimmons> <sgp_ "for the record, who is for focus"> I am as well.
17:39:37 <moneromooo> I'd say yes, on balance. Not a huge preference.
17:39:45 <dEBRUYNE> Triptych is my preference
17:39:46 * dEBRUYNE brb
17:39:53 <sethsimmons> Lets focus on the clearest next step and then think more about Arcturus later if needed.
17:40:13 <sethsimmons> Not enough clear wins in Arcturus to offset the novel assumptions IMO.
17:40:15 <sgp_> my guess is that we will never use Arcuturus since ideally there will be a bigger breakthrough in a few years
17:40:26 <sarang> FWIW the key image structure is identical between the two anyway
17:40:29 <sethsimmons> Most likely, and thats not a bad thing I don't think.
17:40:34 <sarang> So an output migration between them is not needed
17:40:41 <sarang> Very similarly to how we did MLSAG->CLSAG
17:40:48 <sethsimmons> Triptych is a large step forward and will buy a lot of time for the next arms race.
17:40:54 <sarang> Output migration _is_ needed from CLSAG->{Arcturus,Triptych}
17:41:23 <sgp_> okay, so for triptych, what is the next step
17:41:29 <sgp_> funding for sarang?
17:41:33 <sarang> Is multisig important?
17:41:46 <sgp_> oh good point
17:41:51 <sgp_> quick vote
17:41:58 <sarang> Big remaining issues are output set binning/selection/representation, output migration concerns, and multisig if applicable
17:42:01 <ArticMine> I say yes
17:42:03 <moneromooo> It is.
17:42:07 <sethsimmons> <sarang "Is multisig important?"> Does Arcturus not cause the same issues as Triptych?
17:42:13 <sarang> The prove/verify code is already present and working
17:42:16 <ErCiccione[m]> it is, yes
17:42:25 <sarang> Multisig code is not, and is highly nontrivial
17:42:36 <sgp_> Is lack of current hardware wallet support for multisig wallets a blocker, yes/no
17:42:43 <moneromooo> No.
17:42:46 <ArticMine> No
17:42:48 <sethsimmons> no.
17:42:58 <sgp_> I also think no
17:43:05 <sethsimmons> It's such a tiny, tiny percentage of users
17:43:24 <sethsimmons> Better to drastically improve the default privacy assumptions for all users than delay for a tiny subset of those users.
17:44:04 <sarang> To be clear, we do have a way to handle multisig, but it requires additional code and library support for more general group structures (RSA groups)
17:44:35 <sarang> I do not have the expertise in hardware device limitations to know the extent to which this is reasonable on those devices
17:44:40 <sethsimmons> Does that need a HF to implement?
17:44:47 <sarang> Multisig? No
17:44:50 <sethsimmons> Or could it be added after the initial Triptych implementation?
17:44:53 <sarang> You can't tell if a txn uses multisig
17:45:00 <sarang> It's entirely separate
17:45:07 <sethsimmons> Ah, ok, that makes it much clearer than to forgo blocking on multisig
17:45:12 <ArticMine> Then I suggest the route is to get Multisig working on triptych
17:45:17 <sethsimmons> Can focus on initial imp then pivot to musig after.
17:45:24 <sarang> Sure, but if the answer is "Triptych multisig cannot work on our limited hardware devices" then that could be a blocker
17:45:28 <sethsimmons> Or if there are resources work on them in parallel
17:45:36 <sgp_> it's not a blocker
17:45:53 <sarang> OK, just wanted to make it clear that it could be the case that multisig will never practically work on those devices
17:45:58 <sgp_> screw current hardware wallet support for multisig wallets
17:45:59 <ArticMine> Not every user has to use the limited hardware
17:45:59 <sarang> I don't know enough to say for sure
17:46:02 <sgp_> very worthy tradeoff
17:46:11 <Lyza> yeah as long as multisig works I don't think HW devices are essential, and besides they'll likely catch up at some point
17:46:39 <sarang> Note that the multisig approach is based on known techniques, but would warrant additional scrutiny and review
17:46:54 <sarang> I have some basic code demonstrating it in Python
17:47:13 <sarang> (usual DANGER DANGER disclaimer that research code is not reviewed and unsuitable for production use)
17:47:54 <sgp_> okay, so what are the immediate next steps
17:48:06 <ArticMine> The proper process of scrutiny and review has to be followed but I do see a clear part here
17:48:10 <sarang> https://github.com/SarangNoether/skunkworks/tree/inverse-mpc
17:48:18 <ArticMine> path
17:48:40 <sarang> ^ that's the code and algorithm descriptions
17:51:51 <dEBRUYNE> ArticMine: I think sarang means that multisig for 'normal' devices is possible (albeit sophisticated and complex)
17:51:58 <dEBRUYNE> But is ruled out for hardware wallets (devices)
17:52:03 <dEBRUYNE> E.g. Ledger & Trezor
17:52:13 <ArticMine> Which is fine
17:52:20 <sarang> Not necessarily ruled out... but would require a lot of other plumbing
17:52:30 <sarang> Again, I don't have the expertise to make that conclusion
17:52:43 <ArticMine> Since not all users need to use hardware wallets
17:52:52 <dEBRUYNE> There is arguably little benefit currently to pursuing Triptych multisig for hw wallet devices
17:53:11 <dEBRUYNE> ArticMine: And they would be able to use a 'standard' Ledger / Trezor Monero wallet with Triptych
17:53:42 <ArticMine> That is my point
17:53:43 <moneromooo> I don't think we need to care whether it's doable atm. Just add triptych, then software MS, then people from ledger/trezor will work out whether they can. If not, tough.
17:53:55 <sgp_> yeah pretty much
17:54:00 <Lyza> +1
17:54:20 <sgp_> so what's next for adding triptych
17:54:25 <sgp_> what needs to happen first
17:54:46 <sarang> Analysis and decisions around output selection and representation and binning
17:54:51 <sarang> Review
17:54:55 <sarang> Consensus code
17:55:05 <sarang> Multisig, if desired (lots of work on this one)
17:55:14 <moneromooo> With the caveat that, while designing software MS, if two implementation options are equally possible but one is thought to be much easier on hw, that gives it a better chance of being chosen, ceteris paribus.
17:55:15 <sgp_> output selection is an area for potential improvement, but could theoretically be implemented with current alo right?
17:55:19 <sgp_> s/slo/algo
17:56:18 <ArticMine> Multisig for regular hardware
17:56:33 <sarang> If you're selecting large output sets, using binning has many benefits, including size
17:56:47 <sarang> You don't want to do individual representations of each output, presumably...
17:56:59 <dEBRUYNE> sarang: And I guess a way of funding too
17:57:53 <sgp_> sarang: I see output selection as a side optimization project
17:58:02 <sgp_> not as a blocker
17:58:17 <moneromooo> I'd be interested in partial caching of crypto ops with binning, to cut off some constant from O(N) in verification time.
17:58:23 <moneromooo> If at all possible.
18:00:06 <sarang> Depends how you bin, but sure
18:00:20 <sarang> And we can reuse output sets between Triptych proofs in the same transaction (my analysis numbers assume this)
18:01:17 <sgp_> when you say "review" do you mean an audit of the paper? audit of the code? both?
18:01:43 <sarang> I'd say both
18:01:59 <sarang> Dedicated peer review in addition to academic peer review provides higher assurance
18:02:07 <sarang> Especially for something relatively new like this
18:03:12 <sgp_> the code for consensus and output selection are separate areas of code, correct?
18:03:22 <dEBRUYNE> We can just ask the audit team if a widened scope is possible
18:04:25 <sarang> sgp_: probably/hopefully :D
18:04:48 <sgp_> I think that's a super important detail to know :)
18:04:57 <sgp_> since if together, then selection is a blocker
18:05:08 <sarang> I mean, binning should have consensus elements in some cases, to avoid miner stuffing
18:05:09 <sgp_> if separate, then we can start with that code now
18:05:33 <gingeropolous> it should be possible to migrate to triptych and still allow those users that have pre-existing multisig setup to migrate as well?
18:05:53 <sarang> gingeropolous: no
18:05:58 <sarang> that's an important point about multisig
18:06:08 <ArticMine> We need a grandparent period for that
18:06:22 <sgp_> huh?
18:06:47 <sgp_> this wouldn't kill the previous multisig funds after a period
18:07:15 <sgp_> they just would have to spend to a new wallet on triptych
18:07:41 <sarang> Existing non-multig operations would continue to work just fine
18:07:44 <dEBRUYNE> Yeah it's like going from non-RCT to RCT outputs
18:07:56 <sgp_> oh one quick compatibility question
18:08:09 <sgp_> suppose I make a multisig wallet today and publish the normal 4 address
18:08:25 <sgp_> what if someone sends tripytch outputs to that address
18:08:56 <sgp_> are those recoverable?
18:09:22 <sarang> I believe you'd need all parties to use a trusted operation to do so (but it's possible)
18:09:25 <sarang> it's really a question of trust
18:09:44 <sarang> The new multisig operation does not require that trust
18:09:54 <sarang> I'd need to review the specifics of this to be sure
18:09:54 <ArticMine> That is why I suggest a period of time for the transition
18:09:55 <sgp_> for clarification, suppose this is a 2/3 multisig wallet
18:10:06 <sgp_> do you need the support of 2 or 3 people
18:10:36 <sarang> I believe you need just the 2 people, but they can't spend it without a trusted operation
18:10:42 <sgp_> ArticMine: this isn't solved with a transition period afaict
18:10:53 <sgp_> what is a trusted operation?
18:11:25 <sarang> They'd have to recover the output private key in a way that means they both know it
18:11:40 <sarang> As opposed to the non-trusted way, in which they don't learn the other party's share of it
18:12:02 <sarang> This is because of an inversion operation that's the cause of all this multisig tomfoolery
18:12:28 <sarang> and cannot be avoided AFAICT (this is present in other constructions like Arcturus, RCT3, Omniring)
18:13:04 <sarang> It's because they need to construct the key image, which uses this inversion
18:13:10 <ArticMine> So there is a one time issue
18:13:18 <sgp_> let me repeat this back to make sure I understand
18:13:20 <sarang> Yes, but could be very important
18:14:41 <ArticMine> To clarify this issue does not occur going from Triptych to Arcturus
18:14:42 <sgp_> in order to recover triptych funds sent to a pre-triptych multisig wallet, they would need to reconstruct the private key in such a way that all parties who participated would learn the full spend key (and thus could independently send all funds from that wallet, including both clsag and triptych outputs)
18:15:07 <sgp_> so put another way:
18:15:09 <sarang> Yes
18:15:23 <sgp_> the wallet would need to be "converted" from a multisig wallet to a non-multisig wallet first
18:15:42 <sarang> That's a good way of wording it, yes
18:15:52 <sgp_> okay, I understand now :D
18:16:06 <sarang> It's super annoying and could be very problematic for users, I know
18:16:07 <ArticMine> but the conversion only requires the same number of signature as the original multi sig
18:16:14 <ArticMine> Correct?
18:16:20 <sarang> ArticMine: yes
18:16:48 <sarang> I've thought a lot about ways to avoid this inversion stuff, but it's pretty baked in to a lot of the math of this and similar constructions
18:16:57 <sgp_> I think this is something that needs to be approached with care, but is still okay to proceed with care
18:17:32 <sgp_> this is why a transition period doesn't solve ArticMine:
18:17:45 <sgp_> wallets will either receive clsag or triptych outputs
18:18:00 <sgp_> this "conversion" needs to be done when the very first triptych output is received
18:18:37 <sgp_> we may have one more option however, sarang what do you think of this:
18:19:20 <sgp_> first, can clsag multisig wallets spend clsag outputs (only) and make new triptych outputs in a non-trusted way?
18:19:43 <ArticMine> What happen in reverse a CLSAG output sent to a Triptych multisig wallet?
18:20:43 <sarang> sgp_: yes
18:20:55 <sarang> The construction of outputs is identical in both cases
18:21:05 <sarang> The only difference is how key images are computed, which has implications for spends
18:22:13 <UkoeHB__> sarang I may be missing something, at which step in https://github.com/monero-project/research-lab/issues/72 is the full private spend key known to participants?
18:22:16 <sgp_> okay, so we have one other option perhaps that's inelegant
18:23:10 <sgp_> we could change the addresses to be detectable to the sender that it's a newer triptych wallet and perhaps also only allow sending of triptych outputs to those on the wallet side
18:23:40 <sarang> Sorry, I have to take off unfortunately
18:23:54 <sarang> This meeting went much longer than I had expected
18:25:31 <u29601mg6ba93j[m> <sarang "Sorry, I have to take off unfort"> Thanks for your participation. Speaking for myself I learned a lot from your answers
18:25:58 <ArticMine> I propose we reconvene is a week
18:26:02 <ArticMine> in
18:26:21 <sgp_> yeah this was super useful I think
18:37:06 <gingeropolous> indeed.
18:37:32 <ArticMine> Ok next meeting?
18:37:42 <dEBRUYNE> Same time next week?
18:37:55 <ArticMine> That was my suggestion
18:38:33 <dEBRUYNE> Sounds good to me