17:03:03 UkoeHB usually starts it. 17:04:35 I will wing it. Meeting time! https://github.com/monero-project/meta/issues/815 17:04:41 Say hi everyone 17:04:45 Hi 17:04:49 Hello 17:04:59 Hey 17:05:05 Hello 17:05:05 Howdy 17:05:33 Updates: What is everyone working on? 17:05:36 hello 17:07:06 me: have preliminary script to collect all RingCT rings. So far I have used it to check how the P2Pool payout efficiency upgrade has improved effective ring size: https://github.com/Rucknium/misc-research/tree/main/Monero-Effective-Ring-Size 17:07:38 This can be used to check the effect of Mordinals/NFTs on effective ring size if and when I parse tx_extra for Mordinals' designated tag 17:08:03 I’ve been working on adding k-anonymity to the monero block explorer to give users more privacy. 17:08:40 isthmus has closed his work-in-progress CCS to help with computational speedup of OSPEAD due to not enough labour bandwidth. I am seeking other forms of help now. 17:08:51 I'm working on the transaction_history for the seraphis_wallet which will be a layer above the "seraphis_engine". 17:09:07 I have it working for blocks at the moment but need to add a range search to Lmdb to allow for transaction hashes. Hyc is helping me with that 17:09:16 What is k-anonymity? 17:10:01 I explain here https://github.com/moneroexamples/onion-monero-blockchain-explorer/issues/284 17:10:21 Thanks 17:11:02 ah crap got distracted, hi 17:11:38 The deadline for MoneroKon submissions is April 3rd: https://cfp.monerokon.com/2023/cfp 17:11:41 Tl:dr instead of a user requesting a single tx hash which the block explorer can confidently assume belongs to the requesting ip address. They will provide the first 5 characters of the hash and the explorer will return all possible k matches. Hence, k-anonymity 17:12:31 i just started looking into the new rangeproof a bit and try to understand it 17:12:36 hi 17:12:41 hi 17:13:46 To use that, I will just need some HTML with a form and the necessary JavaScript to issue to that newly k-anonymity capable block explorer? 17:13:58 Rucknium: (diego is here on hand for when bp++ peer review funding is to be discussed) 17:14:10 ye 17:14:19 my update: did a refactor of the seraphis scanning framework to better support async backends, right now working on integrating checkpoint caches into the seraphis enote store 17:14:30 Do any other XMR block explorers have k-anonymity? This seems like a great privacy improvement for the general user 17:14:45 plowsof: IMHO, we should discuss that first since tx_extra is potentially unlimited discussion: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/358 17:14:57 rbrunner: yea javascript will be needed, unfortunately, to filter all the data returned 17:15:28 It should be super straightforward from the frontend perspective 17:15:52 xmrack[m]: What about the compact filters approach that Neutrino uses? 17:16:23 I see, thanks 17:16:28 plowsof11: it looks like the bp++ paper is still not updated 17:16:37 xmrack: IMHO, timing is still an issue with 5-character hash prefix. 17:16:44 after 3+ months wait - the bp++ paper has not been updated, and my lines of communication with the author have dried up. correct UkoeHB 17:17:25 depending on how "Range Proofs with Constant Size and Trustless Setup" performs, we could maybe skip bp++ and just use this instead? 17:17:45 plowsof11 I thought blockstream hired him, maybe worth reaching out 17:17:52 You would only get about one tx per week with 5 character prefix I think. Most people look up recent txs 17:18:23 atomfried[m]: it sounds like that new paper is missing a proper security model 17:18:47 I suggested that we return to the CCS after 3 months if there was no paper update. It has been three months 17:18:54 ah 17:19:20 UkoeHB: yes, thats not included in the paper, maybe it was not in the paper due to a pagelimit 17:19:49 Rucknium: timing data should have no effect on this. All data is sent to the client, then the client loops through the data and pulls out the block/tx they want 17:20:14 The authors of the constant size rangeproofs (needs a shorter name!) will be at the meeting next week yes? 17:21:17 The 5 character prefix is subject to change. I need to run benchmarks to see what acceptable bandwidth looks like 17:21:27 move bp++ peer review to funding as is vote? or 17:21:27 blankpage: Good point. Maybe the next step will be clearer once we discuss that paper with the authors 17:21:59 For example we could ask "do you have a security model?" 17:22:14 blankpage: yes they mentioned they were busy today but will be here to answer questions next week 17:22:17 Do we know how far vtnerd is with their BP++ implementation already? 17:22:43 move bp++ peer review to funding as is vote? or wait for next week after constand sized range proofs meetings? 17:23:23 Paper authors sort of vanishing make me a bit nervious ... 17:24:13 Or the CCS is rewritten as "research, implement & audit next generation range proofs" so that it covers b++ and/or the new thing 17:24:13 (Putting up for funding leaves time to raise the money so we are ready when/if. Can always repurpose the funds for alternative solution) 17:24:24 i think its a simple case of : he is now employed / busy on other things, i can make a last attempt to contact blockstream before next weeks meeting? 17:25:28 Blockstream's focus is BTC. They probably don't particularly want to help Monero FWIW 17:25:53 i have this feeling too 17:26:00 blankpage: sounds good to me - anybody against? 17:26:39 xmrack I guess the consideration is whether the block explorer has a powerful heuristic by guessing that the intended query is the most recent of the returned set of k. 17:26:42 Don't have clear and focussed CCS a better resonance than such "this or maybe this"? 17:26:44 I would not be in favor of a CCS that is so vague on what the task is and who would accomplish it 17:27:41 Usually it does not take long to fund a CCS, I would say. We probably won't bump against a wait of, say, a month or so. 17:28:06 Considering the "open ended" nature of this stuff, is MAGIC maybe a better fit? 17:28:46 Well, it's only open ended if we don't bring with us the patience to wait until we have a clear direction :) 17:29:04 xmrack: the problem you're trying to solve is known as "private information retrieval", or PIR, and it's been around for a while. You need homomorphic encryption to make a block explorer that truly knows nothing about what the client is asking for. Such an explorer exists for Bitcoin in an experimental state: https://btc.usespiral.com/ I know the developers and can get you in touch with them so that you can make a similar 17:29:04 one for XMR. 17:29:25 Blockstream uses rangeproofs BTW for confidential amounts on their "liquid network". Idk if they are jumping into this new rangeproof though. 17:29:32 rbrunner: has nothing to do with patience 17:29:33 blankpage: ahhhh I see, I thought you meant side channel timing data like packet times. Guess newest heuristic could be true especially singe I will need to scan the mempool. I will work with Rucknium to figure it out 17:29:39 It uses lattice-based cryptography. 17:29:46 *since 17:30:09 rewrite the ccs = back to the drawing table for quotes from multiple companies 17:30:21 So for now plowsof @plowsof:matrix.org: sounds like do nothing 17:30:36 Alex | LocalMonero | AgoraDesk: sounds interesting 17:30:46 Alex|LocalMonero: could this also work for light wallets? 17:31:25 atomfried[m]: Probably but it's way more complex due to homomorphic encryption constraints. 17:31:27 IMHO, more programmer-cryptographers like koe and kayabanerve should give opinions about what to do about the BP++ paper 17:31:40 And wait for the new rangeproof paper authors next week 17:32:25 xmrack[m]: https://eprint.iacr.org/2022/368 17:32:34 👋 17:33:07 Homomorphic encryption allows you to perform operations on encrypted data without decrypting it. Such as checking an address for txs. 17:33:21 Just finished reading up 17:33:36 The downside is that its very space-inefficient nowadays. 17:33:42 sounds good, we can TBD next week, thanks for attending Diego Salazar 17:33:50 ye 17:33:52 Homomorphic encryption is quite bleeding edge AFAIK...meaning users may get cut 17:33:59 BP++ is beyond me. I can't encourage deployment without review from people its not. 17:34:57 Rucknium[m]: PIR block explorers are probably the least dangerous production battleground to test this tech out. 17:34:57 My one candidate is sarang. I would hold off until this constant time proof has an initial eval. That means source access + benchmarking + a security proof. 17:35:13 Alex | LocalMonero | AgoraDesk: You're probably right. 17:35:18 Currently, I believe the authors didn't make a CSRP sec proof. I have heard commentary the applicability is a bit... Hand waved. 17:35:44 I look forward to hearing more from the authors on the matter. They didn't respond to me, yet someone else. I believe they'll be here next week? 17:35:46 xmrack: https://github.com/ahenzinger/simplepir is currently the fastest PIR server I know. 17:35:50 I don't think BP++ has a security proof either. Does it? 17:36:23 If CSRP doesn't have a sec proof, I'd move forward with BP++. 17:36:56 I believe ++ has a proof, yet also a TODO somewhere in the paper? 17:37:27 I don't believe that TODO is relevant to us but I can double check now. 17:38:05 yeah might as well stop waiting on BP++ 17:38:06 TBC, without a publication for and proof of CSRP, it's interesting but a non starter. 17:38:55 I'm willing to wait a week to hear back from the CSRP authors, as I do believe they're interested in attending next week's meeting... 17:39:20 kayabanerve: Thanks for your input 17:40:19 the peer review is step 1 of , entire project is being delayed imo 17:40:52 BP++, 8.1, proving and verification time is incomplete. 9, proofs, is not. 17:44:27 xmrack: Are they trying to attend the meeting next week? 17:44:45 Yes 17:45:15 Just triple checking :) 17:45:29 I'd call to hold off on any decisions until after then. 17:45:43 But BP++ should be moved forward with. 17:46:09 kayabanerve: "moved forward with"? 17:46:15 And while I don't want to force a topic change, I do have a question for tevador of larger interest. 17:46:44 Rucknium: There's no reason to hold off on it currently, other than potential greater interest in this constant sized proof. 17:47:02 xmrack[m]: Ideas for doing k-anonymity client side without JS, use fragment hash CSS styling of page via targeting https://stackoverflow.com/questions/36552784/change-the-style-of-an-element-if-the-fragment-identifier-hash-in-the-url-refe but the hard part would be sending the user to the proper page (maybe abuse max length on fields) JavaScript 17:47:02 could be needed to redirect user to results page, but not on the filtering part. Maybe good for linking to the page by other places 17:47:13 If the CSRP becomes a non-factor, we should conduct peer review on it. 17:48:12 kayabanerve: Go ahead and change topics 17:49:37 tevador: I don't believe an indirect curve cycle is possible due to the fact we need to do an ECC op *and* membership. Do you have any thoughts on this? 17:50:36 To be clear, the proof needs to substract the blinding factor, then prove the unblinded point is a member. tevador found an efficient indirect cycle, letting us stay on Ed25519, but the indirect cycle *can't* do ECC ops unless it rebuilds a calculator on the arithmetic level. 17:50:44 *binary level 17:50:50 Completely infeasible 17:51:50 So that means we'd need to do ECC ops on the tower, and then use that unblinded point on the cycle. I'm unsure we can efficiently do that since we have to maintain ZK. 17:52:26 We can trivially prove the ECC op on the tower, get the output point, and move that to the cycle. It just wouldn't be ZK. 17:53:13 ... It may be possible with a Pedersen commitment? And then we'd have to prove two EC ops on the tower and open the commitment in the cycle? 17:54:05 Anyways. I wanted to get tevador's thoughts in this and if I wasn't missing anything, move the discussion back to switching curves, despite the potential avoidance noted by tevador. 18:01:03 ... Doesn't seem like we'll get a response this meeting 😅 My thoughts/updates on the SNARK design discussion have been made available. I don't have anything else to say as part of it right now :) Thanks for the opportunity Rucknium: 18:03:06 Meeting is over :) 18:04:21 Thanks for hosting Rucknium, and all in attendance 🙏 18:04:39 Thanks Rucknium ❤️ 18:20:59 Thanks Ruck, Koe, and Kaya