15:23:29 I'm looking back at the BP+ paper. ZenGo found an error in one of the paper's math proofs and suggested a correction. (ZenGo said that the theorem itself was valid once the correction to the math proof had been made.) 15:23:30 The BP+ paper was eventually published in April 2022 here: https://ieeexplore.ieee.org/abstract/document/9758733 15:24:50 It says that the math proofs are "relegated to Appendix", but I don't see an Appendix anywhere on that ^ page. Am I just missing something? Can anyone see an Appendix? 15:25:25 I want to see if the authors changed the math proof in response to (or independently from) the ZenGo finding. 15:33:46 Meeting 1.5hr 16:43:08 How to access the meeting? 16:47:21 it will be here 16:56:07 "it will be here" <- 👍 17:00:39 meeting time https://github.com/monero-project/meta/issues/755 17:00:39 1. greetings 17:00:39 hello 17:00:42 hi 17:00:56 hi 17:01:13 hi! 17:01:14 Hello 17:01:54 Hi 17:01:57 Rucknium[m]: https://eprint.iacr.org/2020/735 17:03:04 UkoeHB: That's the version with the error in the appendix. We can return to that later. 17:03:29 that's the version with an appendix lol 17:03:52 2. updates, what's everyone working on? 17:04:36 my serialization changes/branch have been _basically_ completed, including replacement of the different ZeroMQ json implementation 17:04:50 only a few functional_rpc tests remain before issuing a pr 17:06:06 me: have been sick, otherwise working on finishing touches for multisig + refactoring the library into multiple directories (half done); after that is just the coinbase tx type 17:06:18 https://github.com/vtnerd/monero/tree/replace_p2p_serialization2 is the locaiton 17:06:24 me: Familiarizing myself with previous BulletProofs+ audit process. I asked Diego Salazar from Cypherstack to be available for this meeting so we can discuss details of the BP++ audit CCS. 17:06:34 das me 17:07:30 so it looks like someone audited the paper, and you are preparing for an audit of the yet-to-be-written bp++? or perhaps somene is writing that already 17:07:45 vtnerd: https://github.com/monero-project/research-lab/issues/101 17:08:35 I ah yeah we definitely discussed that, and I forgot initially 17:08:58 although Im a bit worried that we may need to re/write ? eh whatever it'll get done 17:09:09 rewrite the bp++ paper? 17:09:32 no that mysterious implementation lol 17:09:35 we will have to write the code ourselves 17:09:40 oh definitely 17:09:53 yeah thats fine, there's a few people that can do it around 17:09:54 3. let's move to discussion 17:10:24 We could perhaps reduce confusion by calling what CypherStack will do a "Peer review" rather than "audit". 17:10:38 Since they are not auditing any code at this point 17:10:48 part of the work requested from CypherStack https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/358 is a proof of concept 17:11:16 Yes but you cannot audit code you've written yourself 17:11:45 As far as I was aware, the PoC wasn't to be included, but rather was to be used more or less as a benchmarking tool since the other implementation can't be verified. 17:11:54 PoC not yet discussed/finalised/confirmed, only 1a) is covered in that ccs* 17:12:12 ok then take it off the ccs if it's not included... 17:12:13 So we would be doing two pieces of work. A peer review of the paper, and a PoC of the code for benchmarking purposes and comparison to BP+ so see if it's worth inclusion. 17:12:22 now I'm frustrated 17:12:43 "with only (1a) being set in stone / to be achieved by this C" from the CCS 17:13:43 We're obviously happy to do the PoC as well, pending the results of the peer review. 17:13:56 Yeah, maybe put that proposed total timeline somewhere else, so that the CCS text is single-topic without any room for doubt 17:14:02 rehrar: would that be an additional funding round? 17:14:27 yes 17:14:33 got it rbrunner 17:15:09 we can't raise funds for a proof of concept until the paper is audited? or am i totlaly off base here 17:15:45 I'm not convinced how useful a PoC is, unless it's required as a template for the real implementation. 17:15:56 selsta: yes that's why I requested it 17:15:56 Well, maybe the whole BP++ comes crashing down in that peer review, worst case 17:15:57 I mean, in theory both can be raised at once, and if something is found to be terribly wrong with the paper (unlikely), then we just don't do the PoC and the money goes to the GF. 17:15:57 The author has a proof of concept on git already. 17:16:58 then we need to foamlise the scope of this PoC because there was 2 things going on - simply 'benchmarking in c++' (instead of haskell) and then creating something thats 'actually' usable for monero libraries 17:17:05 formalise* 17:19:04 selsta: ok if someone who can read haskell or whatever that is wants to translate it to python/c++... 17:19:16 Why Haskell? What is now in Haskell? The author's PoC? 17:19:40 https://github.com/Liam-Eagen/BulletproofsPP 17:19:53 lol I've always secretly loved haskell ... Im not sure if signing myself up for this is a good idea given other stuff Im doing 17:19:59 but maybe this is more important 17:20:10 Oh wow 17:20:16 and I havent studied haskell in depth, just like what they are trying to do 17:21:27 the tasks Im trying to do are the p2p serialization and p2p e2e encryption 17:21:37 and few other side things, but those are the most relevant to monero 17:21:48 vtnerd: what timeline do you have for those p2p things? 17:21:51 *the above is the most relevant to this discussion 17:21:55 p2p serialization is the one that's almost finished? 17:22:17 This goes over my head, but the "P" in "PoC" stands for "proof", and maybe we don't need any more proof and could directly go to the implementation in Monero codebase 17:22:18 yes. and the p2p encryption has some code but I stopped dead in my tracks because of the tracking issue with the initial proposal 17:22:35 a big advantage of getting the code done in-house is we can ask cypherstack for a code audit in the future 17:22:46 I've actually got to re-write my proposal on that, and follow closer to what bitcoin is doing (I think), but theres a few other details I've got to work through 17:23:20 having a static-key is nice for a few reasons, but it makes the node trackable in a bunch of ways 17:23:37 AFAIK, we're not in a rush here on BP++. We can take things step by step. Probably the only downside to separating the peer review and PoC into two CCS proposals is asking the community twice to fund something. 17:23:52 so Im still mulling over whether a --secret-p2p-key opti-in is a good idea 17:24:12 yeah bp++ seems like it would be more on the seraphis timeline ? 17:24:34 We estimated Seraphis 2 years out, or longer 17:24:47 like thats going to be a major fork anyway, and bp++ in the current mlsag/ringct setup is going to be annoying 17:25:14 More annoying than BP+ then? 17:25:16 I mean it would enable us to bump ringct further, but then we have maintenance on a bp++ w/mslag to think about 17:25:23 is it different from going from bp to bp+? 17:25:43 no its just that bp++ with mlsag adds additional technical debt that we have to maintain in perpuitity for the project 17:25:51 the sooner BP++ is done, the sooner resources tied to that project can be used elsewhere 17:26:27 hmm. well I'll let the others decide whether is higher priority then 17:26:29 plus the longer it takes to integrate, the less available I may end up being 17:26:49 it sounds like bp++ is high priority then 17:26:56 Well, otherwise we have a larger-than-would-have-been blockchain for perpetuity, no? 17:27:13 yes, for me it's high priority 17:27:17 yeah theres that angle too. 17:27:46 ok, sounds like we need bp++ immediately then, if theres a haskell implementation Ill do a straight port 17:27:51 2 years without a hardfork are booring anyway :) 17:27:53 the 'peer review' is promised to be completed in 'around' 12 ~ days 17:28:20 vtnerd: the BP++ author's proof of concept is here https://github.com/Liam-Eagen/BulletproofsPP 17:29:09 one complication with perf comparisons is that the existing bp+ could have speed perf improvements from what I recall 17:29:35 so if I do a port, then I'll probably simateulounyl have to improve the old two implementations to get a better compre 17:29:39 however I'm thinking the existing BP/BP+ files have code duplication that can be pulled into a common library and also used with BP++ (probably) 17:30:12 vtnerd: I don't think there are any perf improvements available, at least in terms of crypto ops 17:31:28 title changed to Bp++ Peer Review, timeline removed. 2 seperate funding rounds for Peer Review and then PoC OR attempt 2 in 1 - if 2 in 1 is voted on - then we need koe to formally right the scope of the PoC 17:31:38 theres some small C++ stuff, like copies in a few areas, etc. Or at least that was my first impression 17:32:33 plowsof: for now I think we should only fund a paper audit / peer review 17:34:13 it will take 'around' 12 days. and the other alternative for the review who got back to me are unavailable until Q2, CypherStack can start 'soon' / "next month" 17:35:28 Ukoehb: I'm only trying to get realistic numbers on bp++. presumably its guaranteed faster to due to algo analysis, etc., so I'll think about that as time permits 17:35:58 Q2, as in Q2, 2023? So many things to audit ... 17:36:04 I support plowsof 's changes to the CCS. I also want to see more detail on exactly which statements and math logic will be checked. The BP++ does not have the familiar "Theorem: Proof" format, so it's not entirely clear what needs to be checked. 17:36:06 yes q2 2023 17:36:14 vtnerd: ok sounds great to me, glad to have your help :) 17:36:21 Im looking at this haskell for the first time, this language is pretty wild lol. but it seems like something I should be able to pick up 17:36:25 Ill notify immediately if I cannot 17:36:43 Thanks, vtnerd 17:36:53 Reading is always easer than writing in a programming language :) 17:37:25 hmmm. maybe, dunno about that 17:37:43 koe thoughts? feeling frustrated still? happy? - we still have time to play with 17:37:58 Rucknium[m] Which statements and math logic do you all want checked? 17:38:10 plowsof: yes this is fine, let's move forward with CCS for cypherstack to do paper audit 17:39:16 We plan to touch on the soundness, completeness, and zero knowledge portions of the paper, as touched on in the paper. We also plan to look at efficiency, aggregation, batching, and MPC compatibility. 17:39:20 rehrar: I'm hoping a cryptographer can answer that. Looks like there are certain statements about soundness, etc. under certain (standard) assumptions in the body of the paper, and then proofs in the appendix. I'm not sure what needs to be checked. 17:39:21 rehrar: presumably the BP++ paper should satisfy the same security requirements as BP and BP+ 17:40:17 I want us to be specific in our understanding so there are no surprises down the road. I'm sure you will do a great job. 17:40:59 UkoeHB that's probably a more realistic standard. Because otherwise we'd be responsible for deciding what needs to be checked, and then checking it. 17:41:41 Which is doable...just a little weird. Us specifying our own work scope. 17:42:09 Typically it's more like the client would provide the preprint and say "please check X, Y, Z on this" and we would, if that makes sense. 17:42:35 yes well :) 17:42:44 But yes, we do have a good understanding of Monero, and BP/BP+, so ensuring it meets the same security requirements as those seems like a solid scope 17:43:42 "Bulletproofs++ use essentially the same model as Bulletproofs(+). The only important differences are either superficial, i.e. using additive vs multiplicative notation for the group operation or the manner in which vectors are decomposed, or in the case of the reciprocal argument a weakening from perfect completeness to statistical completeness." 17:43:46 ^ here is the claim from the paper 17:44:13 One thing to watch out for is novel cryptographic assumptions. Those can be hazardous 17:44:28 Right. So making sure it fits neatly and completely into the place that BP+ currently sits would be a good scope, imo. Disagreements? 17:45:20 +1 17:45:24 none from me, thanks rehrar 17:45:53 Cool. We wouldn't be able to start until early December. Would that be an issue? 17:46:02 that should be fine 17:46:18 makes sense to me rehrar 17:47:15 Cool deal. If no more questions for me, then I'm off. 17:48:09 To be clear, this includes checking the correctness of proofs when "fit[ting] neatly and completely into the place that BP+ currently sits" relies on any proofs in the paper, correct? 17:48:33 yes 17:49:39 Great. Thank you 17:50:06 ok, any other last minute topics we should cover today? 17:51:05 oh btw rehrar should we use this old CCS to fund the new one? https://ccs.getmonero.org/proposals/cypherstack-sarang-triptych-research.html 17:51:27 I have zero control over how the funds on the old CCS are used. 17:51:33 That seems like it'd be a question for core. 17:51:41 they where/yet to be donated to the general fund 17:51:59 ah 17:52:05 seems a sensible request to go to this one , ill ask 17:52:07 Until the money is in my hands, it's core stewarded money 17:52:19 after that it's my money >:) 17:53:35 ok seems like we can wrap it up here, thanks for attending everyone 17:54:32 thanks all! 18:09:23 how ever long it takes* - 'around' 12 days (which is a similar timeframe auditor QuarksLab quoted but they gave a daily cost of (i've not got the exact number now) but it was upwards of 2.x kusd/day) 18:09:23 How many hours of work are covered in this CCS draft? 18:09:50 need some feedback on the draft CFP for monerokon 2023, in particular the topics section 18:10:35 https://cfp.monerokon.com/2023/cfp 18:18:47 "LOCATION: TBD" So still to be defined? 18:19:09 Oops. I was supposed to say during the meeting that the MAGIC Monero Fund committee voted to say that it would partially or completely fund audits or reviews of BP++ after this one is complete. 18:19:11 depends on CCS funding 18:20:45 Ah, if more, it's Prague, if less, it's Neuchatel, right? 18:22:19 https://repo.getmonero.org/ajs/ccs-proposals/-/blob/monerokon-2023-ccs-1/monerokon-2023-ccs-1.md 18:23:39 Thanks, now I remember to have seen that, yeah. 18:24:40 Neuchatel is only about a 1.5 hours train ride from my place ... 18:32:44 Still WIP, so any comments, suggests would be helpful 18:36:54 s/suggests/suggestions/ 22:39:23 https://arxiv.org/pdf/2211.04259.pdf 22:39:39 Towards Measuring The Fungibility and Anonymity of Cryptocurrencies 22:51:35 "[Physical cash] fungibility is ensured and guaranteed by laws." [citation needed] 22:52:57 Interesting paper though. I wonder how hard it would be to apply their measurement method to Monero. 22:55:09 Rucknium[m] "legal tender" means that you must accept. civilians legally can not distinguish one dollar from another dollar. the government can, but not civilians. 22:55:38 now... you can deny business potentially on different grounds, but not based on the serial number of paper money 22:56:26 "legally" is the key word. all bills have serial numbers on them but basically you're not supposed to be paying attention to thaht 22:56:28 that* 22:56:30 NorrinRadd: This is not correct in many jurisdictions. When I requested a citation, I was serious. 22:58:17 Rucknium[m] https://en.wikipedia.org/wiki/Legal_tender 22:59:05 Notes reference #1 23:00:56 I think the citation supports my point 23:02:26 Rucknium[m] i's possible i'm missing some backlog. What is the point you were making? 23:02:33 it's* 23:03:32 Taking this to #monero-research-lounge:monero.social ... 23:03:52 i thought this was linked to that 23:04:04 lol is the lounge on irc? 23:07:12 Yes, lounge is on libera IRC