07:41:01 endor00: is this formall written in a paper/thesis anywhere? You also don't have any variable that accounts for hardware variances, unless i am not understanding? 07:41:52 This is the Cambridge method: https://ccaf.io/cbnsi/cbeci 10:02:47 midipoet not yet finished, unfortunately 10:04:38 The breakeven efficiency is the key here: it's the minimum efficiency (in H/s/W, or H/J) that the hardware needs to have in order to break even with the electricity cost 10:29:33 Looking at their methodology, it's the same as mine: they assume miners use hardware that is profitable - they call "profitability threshold" what I referred to as "breakeven efficiency" (though my formulae are a bit neater imo) 10:31:49 Plus they take into account the release dates and specs and sales data of hardware over time to estimate the average efficiency of the network 10:32:21 (And use the worst and best profitable hardware to estimate the upper and lower bounds for power usage) 15:02:55 MRL meeting here in two hours. 17:00:27 👋 17:00:30 Meeting time! https://github.com/monero-project/meta/issues/957 17:00:44 1) Greetings 17:00:58 👋 17:00:58 hello 17:01:39 Hola. 17:01:48 hi 17:02:49 2) Updates. What is everyone working on? 17:03:24 I implemented GBPs into the FCMP repository. Variety of comments available from that. 17:04:41 me: OSPEAD. Related, I am pretty sure that the late December 2023 increase in tx volume ( https://bitinfocharts.com/comparison/monero-transactions.html#3m ) was someone spending many outputs as quickly as possible. The ring member age distribution shifted to be much younger than usual. In other words, probably spam like July-Aug 2021. 17:05:16 kayabanerve: You can save more time by explaining acronyms on first mention. 17:06:17 me: working on block difficulty computation in the "chain hardening" mode in lws. Still not sure the mode is worth it because I don't plan on having 2+ daemons for point of reference like p2p has 17:06:58 The primary note is my impl is still ongoing. The circuit needs rearchitecture. The low level optimizations no longer still apply. 17:06:59 The next comment is it may yield 2-6x performance increases *more than expected*. I was hoping for 35ms a proof. It may be a small fraction of that. 17:07:05 but basically Im trying to make sure the chain is valid with a certain level of difficulty, to make false chains from the daemon harder 17:07:35 GBPs = Generalized Bulletproofs 17:07:35 FCMPs = Full Chain Membership Proofs 17:07:54 kayabanerve: Did you see this paper? https://eprint.iacr.org/2024/047 "On Efficient and Secure Compression Modes for Arithmetization-Oriented Hashing". Anything applicable? 17:08:36 vtnerd: Similar to bitcoin SPV wallet? 17:08:53 Their abstract is wrong :C 17:09:24 Not a good start 17:09:49 Just the claim Monero uses this. 17:10:17 What makes GBP "generalized"? Why is ordinary BP a special case? 17:10:17 yes, its likely similar. monero-lws is designed to run 24/7, so its got a better chance at detecting timestamp frauds 17:10:19 So we perform a Pedersen hash for free. 17:11:32 Technically, there's the overhead of the second proof needed for its output, and the blinding we need go transfer said values. 17:11:33 The unblinding is done in-circuit and is... 1.25 gates * 161 trits? 250 gates (which are R1CS constraints). I hope to get that to 1. 17:11:38 *200 gates. 17:13:29 3) Discussion. What do we want to discuss? 17:14:44 They're 258 constraints for their smallest space Rucknium. It's competitive, yet don't believe it'd be faster, even though it'd remove the overhead of the other proof. 17:15:19 (sorry if I went too far into the math there) 17:15:22 ^ That's referring to the paper I posted? 17:15:37 *They're 231 17:16:24 You wrote of a probable spam attack late December. How long did that last? 17:17:08 (Maybe not an attack, but spam.) 17:17:27 Yeah. It uses ~15% more constraints. It would let us avoid a second proof, if we trust their hash function. That may be a fair trade off EXCEPT I'm planning to further reduce our constraints *and* we don't have our hash function take more time as the base does (they do. More elements hashed, more steps taken). 17:17:28 rbrunner: About two weeks. Shorter than the July-Aug 2021, which was 6 weeks I think. https://bitinfocharts.com/comparison/monero-transactions.html#3m 17:18:24 I see. And I was hoping people start to buy each other Christmas gifts with Monero en masse ... 17:18:29 So there's a bit of technical commentary which would need a full PoC to properly compare (2w-1m of work?). I don't think it'll end up more competitive *and* it has a fundamentally distinct security analysis. 17:19:15 Here was our analysis of the 2021 incident: https://mitchellpkt.medium.com/fingerprinting-a-flood-forensic-statistical-analysis-of-the-mid-2021-monero-transaction-volume-a19cbf41ce60 17:19:38 I wonder what a spam wave of only 2 weeks should be "good" for 17:21:18 The tx volume chart has a similar shape, too. Spike to double the tx volume, then gradually decrease back to the usual tx volume. 17:23:53 Distinctly, I'd like to raise an idea to note, though I apologize for how I've already spoken quite a bit as I vocalized my analysis of that paper. 17:23:53 Class groups. They're an extremely weird niche of cryptography I used for a side project. I'm also half convinced they're the solution to everything. 17:23:53 We can trustlessly define a class group such that we can operate on arbitrary ECC elements, scalars or field elements, within an EC-like abstraction. 17:23:54 https://eprint.iacr.org/2022/419 is a constant sized, logarithmic verification time, ZK SNARK premised on them. 17:24:05 rbrunner: as Rucknium said, the ring member age distribution shifted to be much younger than usual. Deanonymization in a targeted set of txs., or specific tx., maybe? 17:24:22 I'll make a research issue for it. No discussion is justified at this time. I just want to have people be aware of the term "class groups". 17:25:12 Yes, the spam incident can be a black marble attempt, but just double the tx volume isn't going to help an adversary much. 17:26:09 "solution to everything" meaning finding use in FCMPs as well? 17:32:22 On a different topic: koe did Seraphis performance tests for tx verification ( https://github.com/monero-project/research-lab/issues/91#issuecomment-1047191259 ). But would things be different if storage I/O was part of the verification time? I assume that raising ring size to 128 from 16 would increase the storage I/O requirements because monerod would have to pull all those outp ut public keys from the LMDB for each ring sig verification. 17:32:50 RavFX 🤐 (RavFX) has brought this up. 17:33:28 And how does Curve Trees compare in I/O requirements? 17:33:50 rbrunner: the fact there's a trustless, constant sized, logarithmic verification time SNARK means all proofs we want can be done. At worst, they'd just be horrible garbage with a million statements due to operating over non-native arithmetic. 17:33:51 Class groups do enable people to find subgroups of order of any prime. This was applied in CL15 for an encryption scheme as *the discrete log problem is easy* for their subgroups. I'm double checking now if native arithmetic was enabled within Dew, or if that's future research. 17:33:51 Even if Dew offers it, it won't beat a proper ECC construction, nor do I believe it'd beat a properly applied IVC construction. Class groups are ~2000 bits. Orders of magnitude slower, yet also with currently unique features. 17:33:52 If ECC is a round hole, and we ever have a square peg, we can hammer it in with class groups. That's the main comment at this time. 17:33:53 Do you just have to get the Merkle root from the database? 17:34:37 They have O(1) storage complexity to verify proofs. 17:34:37 They just need the tree root. There's no random reads from disk. 17:35:37 We'd define said root as the root for 10 blocks ago, and once a block is 10 deep, update the tree with that block's new enotes. That does require ECC operations, and my PoC delayed said operations until all enotes were added to demonstrate a batch update. 17:36:54 Maybe the Seraphis I/O performance can be tested once devs in #no-wallet-left-behind:monero.social have a Seraphis database. 17:37:15 I mean Seraphis with 128+ rings 17:37:28 I also guess the tree edges, which are the elements updated, will be concise enough to fit into memory. 17:37:59 Yeah, I don't see anybody building something like a simulation just for such a speed test. Testing can probably indeed start if we have a Seraphis testnet running. 17:40:44 Anything more to discuss? 17:42:32 We can end the meeting here.