12:22:38 re: inflation bug fud - how would that look in practice? receiving extra XMR when getting a payment/change output? that would be very obvious and not "undetectable inflation". also, would those "new" outputs even be spendable? 16:04:30 meeting 1hr 16:13:41 r4v3r23[m]: in practice it would be semantically invalid transactions that validate at consensus, ie txs that look completely normal but don’t have a proper amount balance 16:59:38 meeting time https://github.com/monero-project/meta/issues/719 16:59:38 1. greetings 16:59:38 hello 16:59:57 Hi 17:00:03 Hello 17:00:56 Hello 17:03:43 Hello 17:04:47 2. updates, what is everyone working on? 17:04:50 Won’t be 100% available this meeting unfortunately, but update: submitted perfect-daemon’s PR 7760 socket connection fixes with merge conflicts resolved + some style changes more in line with the rest of the repo (see PR 8426), submitted a patch for zmq to publish txs submitted to the daemon (PR 8427), and updated openmonero for the hf 17:05:48 Mostly doing OSPEAD work. 17:07:16 I'm benchmarking my python code with the c++ code. Thank you for the detailed review on the website UkoeHB ! 17:07:23 I published my new address specification, featured addresses 17:07:41 https://gist.github.com/kayabaNerve/01c50bbc35441e0bbdcee63a9d823789 17:08:30 It's more dev, but I wanted to comment on it as it does remove the burning bug under one variant 17:08:45 I think I will implement bp in rust too by the end of this month or next one. It will be useful to build my skills and I think it may be useful for kayabanerve too 17:09:11 Hi 17:09:29 me: started work on the last big project on my end for seraphis poc -> integrating legacy cryptonote outputs into the main transaction type so they can be spent alongside normal seraphis enotes (instead of two tx types there will be just one, and the cryptonote inputs will be selected from the full range 2014-202x so if/when seraphis goes live there will be ONLY two tx types being created [main tx and coinbase]) 17:11:06 UkoeHB: But the fact that an input is an old cryptonote output would be apparent to observers of the blockchain, correct? Can't mix two output types in the same ring, right? 17:11:13 correct 17:11:23 there would be seraphis inputs and legacy inputs 17:12:06 That will go all the way back to outputs from 2014? 17:12:28 yes, you can use the technique that's currently used with coinbase outputs to spend the cleartext amount outputs 17:12:49 https://github.com/monero-project/research-lab/issues/59 17:13:13 Reassuring 17:15:05 The MAGIC Monero Fund is considering targeted outreach to external researchers to apply for research grants. If you have any in mind, let us know. We would be targeting people who could make a practical contribution to the protocol. 17:15:23 3. discussion, we can move on from updates :) 17:15:54 I was wondering where BP++ stand, not in connection to Monero, but in general as a new cryptographical/mathematical construct. It that "trustworthy" already, or does that need audits / reviews? 17:16:30 AFAIK, BP++ is not peer reviewed yet and was written by a single person. 17:17:00 Ah, yes, "peer review" was the word I was looking for 17:17:04 Rucknium[m]: the main research areas it would be nice to have are in zk circuits for 5th-gen membership proofs and in formalizing current ad hoc algorithms (and adding security modeling/proofs) 17:17:08 https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=83 17:19:19 So I get no mad rush yet to implement them 17:19:55 Maybe coming up with a list of Monero's algorithms and dividing them into formalized and not-yet-formalized would be a good first step. 17:20:24 So that researchers would have a good idea about where to look for improvements 17:24:37 One of the questions in my mind for "zk circuits for 5th-gen membership proofs" is the assumptions that we would like to rely on. For example, Zcash's protocol has newer and less-tested assumptions. Ideally we would want researchers to develop membership proofs with global anonymity sets that rely only on old battle-tested cryptographic assumptions, correct? 17:24:45 Today I want to explain/discuss some of the next steps for seraphis after I am done with my stuff. 17:24:45 My remaining todo: integrate cryptonote inputs (possibly including a new default output scanning workflow for legacy outputs), add coinbase tx type. 17:24:45 Todos after that (not me): investigate/implement the wallet-side features of Jamtis (RIDs, Polyseed, address authentication), build wallets that use the seraphis library interface for building/handling txs and enotes (full wallet, view-only wallet, multisig full wallet, payment validator), integrate seraphis into the daemon/ledger, ... idk what else. 17:25:17 I don't want to instigate cutting-edge research that will be "too" cutting-edge for us to use. 17:25:18 Rucknium[m]: yes the more robust the better (no trusted setup is a requirement) 17:26:40 jberman[m]: has said he wants to work on seraphis/jamtis next steps, it would be nice if anyone else interested could start raising their hands (and start looking at the code to get an understanding how it works) 17:27:11 How do we get the cryptography in Seraphis to be peer-reviewed? 17:27:41 "anyone else interested could start raising their hands" Well, here :) Just not yet sure when, how and how much. 17:28:01 well that is a non-implementation todo of mine -> update the paper more and try to get more cryptographer eyes/contributions on it 17:30:19 rbrunner: I'm definitely interested in contributing for real. I'm just not finished yet on building my skills and understanding. In two months I believe I will be able to start contributing. 17:30:24 I guess I didn't make a public statement about my CCS: I won't actually make a wallet proof-of-concept, since designing the API and internal caches isn't really my domain. The remaining time of my CCS will be spent finishing the core library. 17:31:10 dangerousfreedom: Sounds good. 17:31:27 I basically way underestimated how much work was necessary to reach the point of 'write a wallet'. 17:32:14 I think implementation can start before we have more review / feedback for Seraphis and Jamtis themselves. Only requirement, bascically, that they don't "explode" compeletely 17:32:38 I mean turn out to have some un-fixable hole somewhere 17:32:51 if they explode, that implies lelantus spark will probably explode as well 17:33:29 Speaking of future plans, after OSPEAD I am thinking about researching churning best practices. From reading old GitHub issues, it seems Surae and knacc both made attempts, but did not complete the research. 17:33:55 OSPEAD won't be the final word in research on decoy selection, of course. 17:36:35 UkoeHB: are we using the existing hash_to_curve or elligator2 or...? 17:38:31 kayabanerve[m]: seraphis does not use hash to point except for making generators (which uses the cryptonote hash to point function) 17:39:05 Got it, sorry 17:40:52 are there any questions/comments/other topics to discuss? 17:43:10 Where are the most up to date and complete specifications for jamtis and seraphis? 17:44:34 wernervasquez[m]: aside from https://github.com/UkoeHB/monero/tree/seraphis_lib there are 17:44:34 https://raw.githubusercontent.com/MoneroKon/meta/main/slides/2022/Seraphis%20Balance%20Recovery.pdf 17:44:34 https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 17:44:34 https://github.com/UkoeHB/Seraphis 17:44:50 the monerokon slides are 100% up to date 17:46:09 Thanks. I have some time coming up to put more work in on my library. Want to make sure my footing is sure. 17:47:11 @UkoeHB: thoughts on getting the poc audited and paper reviewed (once both complete), by e.g. veorq? Perhaps we can start opening discussion 17:47:29 no thoughts other than 'good idea' 17:48:20 has polyseed been look at? tevador says its production ready 17:48:28 not by me 17:48:38 there were some concerns raised that 16 words isn't enough entropy 17:49:41 it's only 128 bits yeah? and current seed is 256 bits 17:49:52 tobtoht implemented it already in Feather 17:50:01 If it's at least 128 bits... 17:50:03 *128 bits of security, that is. 17:50:25 They released a few days ago. 17:52:48 Yeah, we go from one possible wallet for each and every atom in the universe to one wallet per molecule or so ... 17:53:16 Or maybe grain of sand :) 17:57:05 Ok I think that's the end of the meeting. Thanks for attending everyone 17:57:41 Thank you for your work Koe! 17:57:51 +1 17:58:44 Bye everyone! 18:25:43 "Yeah, we go from one possible..." <- how does that compare to bitcoins entropy> 19:01:36 Not sure, but I think to remember that Bitcoin also stands at around 128 bits of entropy 19:04:18 Bitcoin's 12 word seeds are 128 bits, yeah. 19:04:18 The polyseed readme claims 150 bits of entropy in the seed, which is bottlenecked by the 126 bits of security in ed25519 so it's there's no point in making it any longer as far as I understand. 19:04:29 Bitcoin addresses are hashed, right? Are encoded points like monero addresses more susceptible to an attack based on low entropy? 19:05:12 Here's where I found the info I just regurgitated: https://github.com/tevador/polyseed#secret-seed 19:07:23 If "attack" means just "try each possible private key" then it probably takes a bit longer if you have to hash as well before you can compare 19:07:39 So 10 times the remaining lifetime of the universe, and not only 5 times ... 19:07:55 I am a bit obsessed with all things universe, you know. 19:08:47 Anyway, who on Earth hacks something nowadays, even something that is almost trivial to hack. Sell the people NFTs, profit, done. 19:08:57 so polyseed is as secure as bitcoin's seed scheme. is there any criticism of that? 19:10:09 It's called "anchoring" in psychology. The current "anker" stands at 256 bits, you go lower, you get questions. 19:12:04 question is if going lower harms security in any tangible way, not just theoreticals. aka is 128 "good enough" for the task, which im assuming it is 19:17:22 a longer seed reduces chance of a collision 19:18:58 assuming ~2^40 user addresses, I believe you'd get a collision with that set in 150 - 40 = 2^110 ops 19:20:16 Isn't the whole question moot, like tevador seems to argue on GitHub, that if do operations on the ed25519 curve afterwards with your "entropy" you loose any bits beyond 128 anyway? 19:23:13 Fun napkin math on time to break any one specific 128-bit key: If we could check keys at the same rate as the bitcoin hashrate of 165EH/s (which we can't), it'd take 2^128/(165x10^18 * 60 * 60 * 24 * 365) = 65 billion years. 19:23:49 BusyBoredom[m]: so polyseed is secure af 19:24:22 the rho attack can break any private key in ~2^125 steps, even if you use a 256-bit seed 19:24:51 yes ~128 is the max, but you can get lower than that 19:25:38 for example, if your private key was in the range [0, 2^128], then your private key only has 64 bits of security 19:26:42 seeds don't have uniform entropy? 19:28:14 What do you mean? I only have to check 2^64 values? I am afraid that's too high for me :) 19:28:17 when you are hashing, you only have collision resistance equal to half the bits of the input variance 19:28:52 rbrunner: you need > 90 bits to be secure iirc (or maybe 100) 19:28:57 Ah, ok, collision resistance, slightly different problem 19:29:22 no, I am talking about two things 19:29:50 "for example, if your private key was in the range [0, 2^128], then your private key only has 64 bits of security" -> this is 2^64 ops to reveal any private key 19:30:13 if you select your private key uniformly from [1, ℓ-1], you'll get the full ~126-bit strength 19:30:27 "when you are hashing, you only have collision resistance equal to half the bits of the input variance" -> this is 2^{variance bits / 2} ops to find SOME collision 19:32:07 if you have a specific set you want to collide with at least once, it is 2^{variance bits - collision set bits} ops 19:34:57 tevador: yes, selecting uniformly at random means you won't have any DLP weakness. But if your selection variance is too low then collisions can be brute forced. 19:37:58 polyseed uses a 150-bit secret seed, so you'd need to attack ~17 million seeds simultaneously to break at least one key with 2^126 ops 19:41:41 tevadorcan you give a quick ELI5 explainaion for why a normal user should choose polyseed over 25 words? 19:48:47 two biggest reasons are: shorter seed, embedded wallet birthday 19:49:41 there have been many support cases that are basically "I restored my wallet from the seed and my balance is 0. Help." 19:49:58 -> because they entered the wrong restore height 19:55:33 and response to the lower entropy arguement? 19:55:56 shorter seed & restore height are major improvements 19:59:25 "lower entropy argument" is just a misunderstanding of how attacks against EC-based public keys work 20:01:50 tevador: what is your safety factor (in bits)? 20:02:57 against a single seed? if the attacker knows the month when the seed was created, the work factor is 2^150 20:03:31 tevador: from what i (a non technical user) understood, the security between polyseeds 128 vs current seeds 256 is a non issue 20:04:21 tevador: taking into account all plausible attack scenarios 20:04:25 UkoeHB: I don't follow why you say a 128 bit key has only 64 bits of security. What is weakening it? If you gimme some words to search I can Google my way to understanding. 20:04:32 the lowest safety factor in bits 20:05:00 BusyBoredom[m]: 128 bit keys have 64 bit security according to the giant step baby step algorithm 20:06:33 assuming fewer than 17 million new seeds are generated per month, the best multitargeted attack is at least as hard as Rho (and probably much harder if the KDF is assumed to provide additional ~12 bits) 20:07:18 idk what you are referring to with 'Rho' 20:07:54 Pollard's Rho attack 20:07:56 "giant step baby step algorithm" Huh? 20:08:15 the same attack works against hash functions 20:08:33 https://en.wikipedia.org/wiki/Baby-step_giant-step 20:08:46 it breaks an N-bit ECDLP in 2^(N/2) steps 20:09:29 "the same attack works against hash functions" this is ambiguous 20:09:31 rbrunner: baby step giant step is another type of attack 20:09:47 hash functions have collision resistance and preimage resistance 20:11:24 UkoeHB: some article references are here in the bottom: https://safecurves.cr.yp.to/rho.html 20:11:57 it's currently the fastest known method to break ECDLP 20:19:45 tevador: the date only adds around 7-8 bits, so I guess that means you have 158 bits of variance total 20:20:47 if it is on a per-month basis 20:23:10 yes, ~160 bits total, plus perhaps 10 additional bits from the KDF 20:23:25 how do you get more bits from a KDF? 20:23:40 if you compare EC point addition to PBKDF2 with 10k iterations 20:24:15 oh like a kind of PoW barrier? 20:24:34 something like that, it's the constant factor of the attack (cost per one step) 20:26:41 r4v3r23[m]: the main takeway is that the current 256-bit seed provides only 128 bits security, not 256 bits 20:27:56 Ok assuming a 40-bit upper bound on collision surface, that's around 130 bits of EC-attack-equivalent cost for a collision, which leaves around 20-30 bits of security factor (which is typically what you want). 20:28:04 tevador: so equal to polyseed then? 20:29:46 or in other words, attack cost on par with the DLP 20:29:55 r4v3r23[m]: yes 20:32:00 excellent. no real drawbacks then, if any. thanks for the explaination